README.md: format CLI commands with code syntax #247
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
CLI commands which are mentioned in the readme are now formatted with the Markdown code syntax to make the documentation more readable. Signed-off-by: Benjamin Dopplinger <b.dopplinger@gmail.com>
|
i dont need to git..... On Mon, May 30, 2016 at 8:22 AM, Benjamin Dopplinger <
|
|
Patch was now submitted through http://submitgit.herokuapp.com and can be found here: |
ttaylorr
added a commit
to ttaylorr/git
that referenced
this pull request
Nov 20, 2023
When trying to resolve a revision query like "HEAD~~~~~", our call
pattern looks something like:
- object-name.c::get_oid_with_context()
- object-name.c::get_oid_1()
- object-name.c::get_nth_ancestor()
- object-name.c::get_oid_1()
- ...
With `get_nth_ancestor()` and `get_oid_1()` mutually recurring, popping
one '~' off of the revision query for each round of the recursion.
Since this recursive behavior is unbounded, having too many "~"'s
contained in a revision query will cause us to blow the stack.
Generating a message like this when compiled under SANITIZE=address:
$ valgrind git rev-parse "HEAD$(perl -e "print \"~\" x 1000000000000")"
==597453== Memcheck, a memory error detector
==597453== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==597453== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==597453== Command: /home/ttaylorr/local/bin/git.compile diff HEAD~~~~~~~~~~~~[...]
==597453==
AddressSanitizer:DEADLYSIGNAL
=================================================================
==597453==ERROR: AddressSanitizer: stack-overflow on address 0x7fffdd838ff8 (pc 0x7f2726082748 bp 0x7fffdd839110 sp 0x7fffdd839000 T0)
#0 0x7f2726082748 in __asan::GetTLSFakeStack() ../../../../src/libsanitizer/asan/asan_fake_stack.cpp:176
#1 0x7f2726082748 in GetFakeStackFast ../../../../src/libsanitizer/asan/asan_fake_stack.cpp:193
#2 0x7f27260833de in OnMalloc ../../../../src/libsanitizer/asan/asan_fake_stack.cpp:207
#3 0x7f27260833de in __asan_stack_malloc_1 ../../../../src/libsanitizer/asan/asan_fake_stack.cpp:256
#4 0x563f9077d9d8 in get_nth_ancestor /home/ttaylorr/src/git/object-name.c:1087
#5 0x563f9077e957 in get_oid_1 /home/ttaylorr/src/git/object-name.c:1295
git#6 0x563f9077da64 in get_nth_ancestor /home/ttaylorr/src/git/object-name.c:1092
#7 0x563f9077e957 in get_oid_1 /home/ttaylorr/src/git/object-name.c:1295
git#8 0x563f9077da64 in get_nth_ancestor /home/ttaylorr/src/git/object-name.c:1092
[...]
git#247 0x563f9077e957 in get_oid_1 /home/ttaylorr/src/git/object-name.c:1295
git#248 0x563f9077da64 in get_nth_ancestor /home/ttaylorr/src/git/object-name.c:1092
SUMMARY: AddressSanitizer: stack-overflow ../../../../src/libsanitizer/asan/asan_fake_stack.cpp:176 in __asan::GetTLSFakeStack()
==597453==ABORTING
(Note that the actual stack is much deeper. GDB reports that the bottom
of the stack looks something like the following):
#54866 0x0000555555c6d3bf in get_oid_with_context_1 (repo=0x5555563849a0 <the_repo>, name=0x7fffffff4be5 "HEAD", '~' <repeats 196 times>..., flags=128, prefix=0x0, oid=0x7ffff5713d40, oc=0x7ffff5713d90) at object-name.c:1947
#54867 0x0000555555c6e2fa in get_oid_with_context (repo=0x5555563849a0 <the_repo>, str=0x7fffffff4be5 "HEAD", '~' <repeats 196 times>..., flags=128, oid=0x7ffff5713d40, oc=0x7ffff5713d90) at object-name.c:2096
#54868 0x0000555555d8eed8 in handle_revision_arg_1 (arg_=0x7fffffff4be5 "HEAD", '~' <repeats 196 times>..., revs=0x7ffff5b000d0, flags=0, revarg_opt=0) at revision.c:2174
#54869 0x0000555555d8f1a9 in handle_revision_arg (arg=0x7fffffff4be5 "HEAD", '~' <repeats 196 times>..., revs=0x7ffff5b000d0, flags=0, revarg_opt=0) at revision.c:2189
#54870 0x0000555555d97ca9 in setup_revisions (argc=2, argv=0x7fffffff4970, revs=0x7ffff5b000d0, opt=0x0) at revision.c:2932
#54871 0x00005555557d6a63 in cmd_diff (argc=2, argv=0x7fffffff4970, prefix=0x0) at builtin/diff.c:502
#54872 0x00005555557367bf in run_builtin (p=0x5555561c4c30 <commands+816>, argc=2, argv=0x7fffffff4970) at git.c:469
#54873 0x000055555573716b in handle_builtin (argc=2, argv=0x7fffffff4970) at git.c:723
#54874 0x000055555573785a in run_argv (argcp=0x7ffff56028b0, argv=0x7ffff56028e0) at git.c:787
#54875 0x0000555555738626 in cmd_main (argc=2, argv=0x7fffffff4970) at git.c:922
#54876 0x00005555559d3fdd in main (argc=3, argv=0x7fffffff4968) at common-main.c:62
Fortunately, we can impose a limit on the maximum recursion depth we're
willing to accept when resolving queries like the above without
significantly impeding users. This patch sets the limit at 4096, though
we could probably increase that limit depending on the size of each
frame.
The limit introduced here is large enough that any reasonable query
should still run to completion, but small enough that if the frame size
were to significantly increase, our protection would still be effective.
The change here is straightforward: each call to get_nth_ancestor()
increases a counter, and then decrements that counter before returning.
The diff is a little noisy since there are a handful of return paths
from `get_nth_ancestor()`, all of which need to decrement the depth
variable.
Since this is a local-only exploit, a user would have to be tricked into
running such a query by an adversary. Even if they were successfully
tricked into running the malicious query, the blast radius is limited to
a local stack overflow, which does not have meaningful paths to remote
code execution, arbitrary memory reads, or any more grave security
concerns.
Reported-by: Carlos Andrés Ramírez Cataño <antaigroupltda@gmail.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
ttaylorr
added a commit
to ttaylorr/git
that referenced
this pull request
Oct 12, 2024
When trying to resolve a revision query like "HEAD~~~~~", our call
pattern looks something like:
- object-name.c::get_oid_with_context()
- object-name.c::get_oid_1()
- object-name.c::get_nth_ancestor()
- object-name.c::get_oid_1()
- ...
With `get_nth_ancestor()` and `get_oid_1()` mutually recurring, popping
one '~' off of the revision query for each round of the recursion.
Since this recursive behavior is unbounded, having too many "~"'s
contained in a revision query will cause us to blow the stack.
Generating a message like this when compiled under SANITIZE=address:
$ valgrind git rev-parse "HEAD$(perl -e "print \"~\" x 1000000000000")"
==597453== Memcheck, a memory error detector
==597453== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==597453== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==597453== Command: /home/ttaylorr/local/bin/git.compile diff HEAD~~~~~~~~~~~~[...]
==597453==
AddressSanitizer:DEADLYSIGNAL
=================================================================
==597453==ERROR: AddressSanitizer: stack-overflow on address 0x7fffdd838ff8 (pc 0x7f2726082748 bp 0x7fffdd839110 sp 0x7fffdd839000 T0)
#0 0x7f2726082748 in __asan::GetTLSFakeStack() ../../../../src/libsanitizer/asan/asan_fake_stack.cpp:176
#1 0x7f2726082748 in GetFakeStackFast ../../../../src/libsanitizer/asan/asan_fake_stack.cpp:193
#2 0x7f27260833de in OnMalloc ../../../../src/libsanitizer/asan/asan_fake_stack.cpp:207
#3 0x7f27260833de in __asan_stack_malloc_1 ../../../../src/libsanitizer/asan/asan_fake_stack.cpp:256
#4 0x563f9077d9d8 in get_nth_ancestor /home/ttaylorr/src/git/object-name.c:1087
#5 0x563f9077e957 in get_oid_1 /home/ttaylorr/src/git/object-name.c:1295
git#6 0x563f9077da64 in get_nth_ancestor /home/ttaylorr/src/git/object-name.c:1092
#7 0x563f9077e957 in get_oid_1 /home/ttaylorr/src/git/object-name.c:1295
git#8 0x563f9077da64 in get_nth_ancestor /home/ttaylorr/src/git/object-name.c:1092
[...]
git#247 0x563f9077e957 in get_oid_1 /home/ttaylorr/src/git/object-name.c:1295
git#248 0x563f9077da64 in get_nth_ancestor /home/ttaylorr/src/git/object-name.c:1092
SUMMARY: AddressSanitizer: stack-overflow ../../../../src/libsanitizer/asan/asan_fake_stack.cpp:176 in __asan::GetTLSFakeStack()
==597453==ABORTING
(Note that the actual stack is much deeper. GDB reports that the bottom
of the stack looks something like the following):
#54866 0x0000555555c6d3bf in get_oid_with_context_1 (repo=0x5555563849a0 <the_repo>, name=0x7fffffff4be5 "HEAD", '~' <repeats 196 times>..., flags=128, prefix=0x0, oid=0x7ffff5713d40, oc=0x7ffff5713d90) at object-name.c:1947
#54867 0x0000555555c6e2fa in get_oid_with_context (repo=0x5555563849a0 <the_repo>, str=0x7fffffff4be5 "HEAD", '~' <repeats 196 times>..., flags=128, oid=0x7ffff5713d40, oc=0x7ffff5713d90) at object-name.c:2096
#54868 0x0000555555d8eed8 in handle_revision_arg_1 (arg_=0x7fffffff4be5 "HEAD", '~' <repeats 196 times>..., revs=0x7ffff5b000d0, flags=0, revarg_opt=0) at revision.c:2174
#54869 0x0000555555d8f1a9 in handle_revision_arg (arg=0x7fffffff4be5 "HEAD", '~' <repeats 196 times>..., revs=0x7ffff5b000d0, flags=0, revarg_opt=0) at revision.c:2189
#54870 0x0000555555d97ca9 in setup_revisions (argc=2, argv=0x7fffffff4970, revs=0x7ffff5b000d0, opt=0x0) at revision.c:2932
#54871 0x00005555557d6a63 in cmd_diff (argc=2, argv=0x7fffffff4970, prefix=0x0) at builtin/diff.c:502
#54872 0x00005555557367bf in run_builtin (p=0x5555561c4c30 <commands+816>, argc=2, argv=0x7fffffff4970) at git.c:469
#54873 0x000055555573716b in handle_builtin (argc=2, argv=0x7fffffff4970) at git.c:723
#54874 0x000055555573785a in run_argv (argcp=0x7ffff56028b0, argv=0x7ffff56028e0) at git.c:787
#54875 0x0000555555738626 in cmd_main (argc=2, argv=0x7fffffff4970) at git.c:922
#54876 0x00005555559d3fdd in main (argc=3, argv=0x7fffffff4968) at common-main.c:62
Fortunately, we can impose a limit on the maximum recursion depth we're
willing to accept when resolving queries like the above without
significantly impeding users. This patch sets the limit at 4096, though
we could probably increase that limit depending on the size of each
frame.
The limit introduced here is large enough that any reasonable query
should still run to completion, but small enough that if the frame size
were to significantly increase, our protection would still be effective.
The change here is straightforward: each call to get_nth_ancestor()
increases a counter, and then decrements that counter before returning.
The diff is a little noisy since there are a handful of return paths
from `get_nth_ancestor()`, all of which need to decrement the depth
variable.
Since this is a local-only exploit, a user would have to be tricked into
running such a query by an adversary. Even if they were successfully
tricked into running the malicious query, the blast radius is limited to
a local stack overflow, which does not have meaningful paths to remote
code execution, arbitrary memory reads, or any more grave security
concerns.
Reported-by: Carlos Andrés Ramírez Cataño <antaigroupltda@gmail.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
CLI commands which are mentioned in the readme are now formatted with
the Markdown code syntax to make the documentation more readable.