| Message ID | 20220507163508.78459-3-carenas@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | fix `sudo make install` regression in maint | expand |
Carlo Marcelo Arenas Belón <carenas@gmail.com> writes: > + /* > + * env_id could underflow/overflow in the previous call > + * and if it will still fit in a long it will not report > + * it as error with ERANGE, instead silently using an > + * equivalent positive number that might be bogus. > + * if uid_t is narrower than long, it might not fit, > + * hence why we need to check it against the maximum > + * possible uid_t value before accepting it. > + */ > + if (!*endptr && !errno && env_id <= (uid_t)-1) > + *id = env_id; Thanks for very clearly spelling out why you care. It makes it much easier to explain why I disagree with the line of reasoning ;-) This code may be exercised by a potential attacker, but we know that the codepath is entered only when euid==ROOT_UID. The attacker may or may not have used 'sudo', and we cannot trust the value of SUDO_UID at all. But that is OK. If the attacker already is root on the box, they do not have to use "git" or exercise this new code in order to attack anybody on the box already. This requires us to exclude social engineering attack to tell a victim to run "sudo", set SUDO_UID to a specific value, and run something, but at last I have been excluding that from the beginning. There are easier things you can tell the potential victim to cause harm while being root. Now the whole point of adding this new code to _weaken_ the existing check is to help legitimate users who are authorised to become root via "sudo" on the box. Making it easier for them to use "git" while tentatively gaining root priviledge so that they can do "make install" in a repository they own. We know that this code is meant to be exercised after a potential victim gained euid==ROOT_UID via 'sudo', and SUDO_UID is exported by the command for the original user. If uid_t is narrower than ulong (e.g. 16-bit uid_t vs 64-bit ulong), and if it is unsigned, the only effect the extra check is doing is to exclude the unfortunate user with uid==65535 from using "sudo git describe". In exchange, the only attack scenario the code prevents is this, IIUC. * You, the aspiring cracker, are a user not allowed to run "sudo" on the box, and you know your uid is 1000 * You look for another user, a potential victim, whose uid is 1000 modulo 65536 (if your uid_t is 16-bit) and who can run "sudo" on the box. * You prepare a malicious repository, invite that user there and ask them to run "sudo something" there. I'd say such an attack vector is not likely, and a user with maximum allowed uid_t value is equally not that likely, so I do not care too deeply either way---and in such a case, I do prefer a simpler code.
On Sat, May 07, 2022 at 10:34:44AM -0700, Junio C Hamano wrote: > Carlo Marcelo Arenas Belón <carenas@gmail.com> writes: > > > + /* > > + * env_id could underflow/overflow in the previous call > > + * and if it will still fit in a long it will not report > > + * it as error with ERANGE, instead silently using an > > + * equivalent positive number that might be bogus. > > + * if uid_t is narrower than long, it might not fit, > > + * hence why we need to check it against the maximum > > + * possible uid_t value before accepting it. > > + */ > > + if (!*endptr && !errno && env_id <= (uid_t)-1) > > + *id = env_id; > > Thanks for very clearly spelling out why you care. It makes it much > easier to explain why I disagree with the line of reasoning ;-) Funny enough the comment doesn't even scratch the surface on the genius of that (uid_t)-1 and how it also prevents people with a signed uid_t to misuse this code as well, while still allowing uid_t > INT_MAX. As mentioned in the cover letter, the code without this is indeed broken and unsafe to use in that case, so we will need to do something else (as spelled there as well), I we were to proceed with it, which as I said before I am totally OK with (granted we do that something else, and promess not to misuse this somewhere later and open us to a potentially embarrasing bug. > This code may be exercised by a potential attacker, but we know that > the codepath is entered only when euid==ROOT_UID. The attacker may > or may not have used 'sudo', and we cannot trust the value of > SUDO_UID at all. But that is OK. If the attacker already is root > on the box, they do not have to use "git" or exercise this new code > in order to attack anybody on the box already. This requires us to > exclude social engineering attack to tell a victim to run "sudo", > set SUDO_UID to a specific value, and run something, but at last I > have been excluding that from the beginning. There are easier > things you can tell the potential victim to cause harm while being > root. Agree, but even if I put a scary looking warning and tried to make this code harder to use than it needs to be, is fairly visible and there had been already suggestions of removing that restriction. Which is why I said this is more a defensive programming solution than real protection under the current constrains. > Now the whole point of adding this new code to _weaken_ the existing > check is to help legitimate users who are authorised to become root > via "sudo" on the box. Making it easier for them to use "git" while > tentatively gaining root priviledge so that they can do "make > install" in a repository they own. > > We know that this code is meant to be exercised after a potential > victim gained euid==ROOT_UID via 'sudo', and SUDO_UID is exported by > the command for the original user. If uid_t is narrower than ulong > (e.g. 16-bit uid_t vs 64-bit ulong), and if it is unsigned, the only > effect the extra check is doing is to exclude the unfortunate user > with uid==65535 from using "sudo git describe". not quite, the check does "<=" so excludes no legitimate users, what is excludes is bit multiplers of those valid users ids to work, so if an obviously impossible to get legitimately and therefore bogus if uid_t is 16bit value of 65536 even gets here we will not assume it was root instead, which I would find personally embarrasing. > In exchange, the only attack scenario the code prevents is this, > IIUC. > > * You, the aspiring cracker, are a user not allowed to run "sudo" on > the box, and you know your uid is 1000 > > * You look for another user, a potential victim, whose uid is 1000 > modulo 65536 (if your uid_t is 16-bit) and who can run "sudo" on > the box. > > * You prepare a malicious repository, invite that user there and > ask them to run "sudo something" there. > > I'd say such an attack vector is not likely, and a user with maximum > allowed uid_t value is equally not that likely, so I do not care too > deeply either way---and in such a case, I do prefer a simpler code. as I do as well, but this is only 4 characters long and getting rid of it means we now have to do either of : * hope nobody has a signed uid_t as this code is broken in that case and will misbehave widly, more importantly we also lost our only way to find them and warn them ahead of time that they need to patch it. * add some aditional way to detect it and avoid this code and maybe even provide an alternative. and also : * move back to strtol and potentially break the feature for half the valid users if uid_t is 32-bit unsigned as it is most likely to be in 32-bit systems. * move to an even wider integer so it will be always wider than uid_t which means we have to move a lot more code around at least. Carlo
Carlo Marcelo Arenas Belón <carenas@gmail.com> writes: >> In exchange, the only attack scenario the code prevents is this, >> IIUC. >> >> * You, the aspiring cracker, are a user not allowed to run "sudo" on >> the box, and you know your uid is 1000 >> >> * You look for another user, a potential victim, whose uid is 1000 >> modulo 65536 (if your uid_t is 16-bit) and who can run "sudo" on >> the box. >> >> * You prepare a malicious repository, invite that user there and >> ask them to run "sudo something" there. >> >> I'd say such an attack vector is not likely,... Sorry, I was totally wrong here. It is not just "not likely", but such an attack, with a potential victim not futzing with SUDO_UID environment themselves, would not work at all. The value of SUDO_UID and the original uid of the potential victim by definition should fit in the uid_t type. So if you, the aspiring cracker, have UID 1000, nobody else on the system has UID that is congruent modulo uid_t and wrap-around attack does not exist. As long as the type we use to read SUDO_UID string into a variable is not narrower than uid_t, there. Of course you can tell any user who runs "sudo" to set SUDO_UID to 1000 + 64k and cause wrap-around, but then you can tell them to set SUDO_UID to 1000 without relying on wrap-around and have the same effect. So, let's stop worrying about this bogus scenario. As to the "we can break compilation with -Wsign-compare on a system with signed uid_t", I agree that is true if we have env_id <= (uid_t) -1 there. But I am not sure if that is the most effective way to smoke out platforms where this code has trouble working correctly. Also, I would think that a system with signed uid_t is a possibility, but a user with a negative UID? I do not think even nobody4 was negative ;-)
On May 9, 2022 12:55 PM, Junio C Hamano wrote: >Carlo Marcelo Arenas Belón <carenas@gmail.com> writes: > >>> In exchange, the only attack scenario the code prevents is this, >>> IIUC. >>> >>> * You, the aspiring cracker, are a user not allowed to run "sudo" on >>> the box, and you know your uid is 1000 >>> >>> * You look for another user, a potential victim, whose uid is 1000 >>> modulo 65536 (if your uid_t is 16-bit) and who can run "sudo" on >>> the box. >>> >>> * You prepare a malicious repository, invite that user there and >>> ask them to run "sudo something" there. >>> >>> I'd say such an attack vector is not likely,... > >Sorry, I was totally wrong here. > >It is not just "not likely", but such an attack, with a potential victim not futzing with >SUDO_UID environment themselves, would not work at all. The value of >SUDO_UID and the original uid of the potential victim by definition should fit in the >uid_t type. So if you, the aspiring cracker, have UID 1000, nobody else on the >system has UID that is congruent modulo uid_t and wrap-around attack does not >exist. As long as the type we use to read SUDO_UID string into a variable is not >narrower than uid_t, there. > >Of course you can tell any user who runs "sudo" to set SUDO_UID to >1000 + 64k and cause wrap-around, but then you can tell them to set SUDO_UID to >1000 without relying on wrap-around and have the same effect. So, let's stop >worrying about this bogus scenario. > >As to the "we can break compilation with -Wsign-compare on a system with signed >uid_t", I agree that is true if we have > > env_id <= (uid_t) -1 > >there. But I am not sure if that is the most effective way to smoke out platforms >where this code has trouble working correctly. Also, I would think that a system >with signed uid_t is a possibility, but a user with a negative UID? > >I do not think even nobody4 was negative ;-) I can test the code when it's ready.
On Mon, May 9, 2022 at 9:54 AM Junio C Hamano <gitster@pobox.com> wrote: > > It is not just "not likely", but such an attack, with a potential > victim not futzing with SUDO_UID environment themselves, would not > work at all. The value of SUDO_UID and the original uid of the > potential victim by definition should fit in the uid_t type. So if > you, the aspiring cracker, have UID 1000, nobody else on the system > has UID that is congruent modulo uid_t and wrap-around attack does > not exist. As long as the type we use to read SUDO_UID string into > a variable is not narrower than uid_t, there. correct; would adding a less elegant "static_assert" (obviously not available in C99) in the code an alternative?, or you are suggesting that documenting that constrain should be done in a comment and hope it doesn't get ignored in the future, or maybe gets instead made less likely to fail by some additional work, like the one I suggested to do later by moving this code around and using intmax_t instead? not that there are 2 different scenarios which we might seem to be flip flopping about : 1) victim gets attacked by tricking them into using the wrong SUDO_UID unlikely to be useful as you pointed out, and totally useless if we still restrict this code to run only as root 2) attacker using this code to elevate privileges themselves only useful if this code is not run as root. My concern again, is not with this code AS-IS but how it might be used in the future. > Of course you can tell any user who runs "sudo" to set SUDO_UID to > 1000 + 64k and cause wrap-around, but then you can tell them to set > SUDO_UID to 1000 without relying on wrap-around and have the same > effect. So, let's stop worrying about this bogus scenario. bogus only if we are still only running this code as root, of course. > As to the "we can break compilation with -Wsign-compare on a system > with signed uid_t", I agree that is true if we have Apologies for not documenting it until now, but I had -Wtautological-constant-out-of-range-compare in mind instead, but your are correct either one would work and the point was that (without having to add even an "static assert") we were able to find them and warn them that they need to patch. > env_id <= (uid_t) -1 If that was not enough, that simple code ALSO disabled the code in that case to make sure they MUST patch locally if they need to make it work, or come back to us to figure out a portable way to accommodate them in the future, with all the information about their system we currently lack. > there. But I am not sure if that is the most effective way to smoke > out platforms where this code has trouble working correctly. Also, > I would think that a system with signed uid_t is a possibility, but > a user with a negative UID? It doesn't need to be a real user (specially if someone independently decides to remove the restriction that keeps this code available only to root). The fact that it was negative but was treated as a positive number on our code just makes the wraparound we decided to ignore before more likely to work without triggering alarms somewhere else and because we decided to ignore an unlikely to be useful positive wraparound, we also would fall from the negative wraparound here that would had protected this code from both if that humble line of code wouldn't had been removed. In your hypothetical system where uid_t is 16-bit (hence 15-bit for valid non-negative ids if uid_t is signed, since no sane system would have negative ones), either 65536 or -65536 would become 0, as well as at least the other 2^16 possibilities that a larger long would provide. If the size difference is even smaller (ex: uid_t is signed int), so the type we are using to parse those values is only 1 bit wider it will still be a concern IMHO. I know people that wrote code to check if "/" was writable as means to make sure they were "root", because that is what any sane system would do, and then came Windows and even in 2022 anyone can write to "/" there and create subdirectories. Carlo
On May 9, 2022 2:49 PM, Carlo Arenas wrote: >On Mon, May 9, 2022 at 9:54 AM Junio C Hamano <gitster@pobox.com> wrote: >> >> It is not just "not likely", but such an attack, with a potential >> victim not futzing with SUDO_UID environment themselves, would not >> work at all. The value of SUDO_UID and the original uid of the >> potential victim by definition should fit in the uid_t type. So if >> you, the aspiring cracker, have UID 1000, nobody else on the system >> has UID that is congruent modulo uid_t and wrap-around attack does not >> exist. As long as the type we use to read SUDO_UID string into a >> variable is not narrower than uid_t, there. > >correct; would adding a less elegant "static_assert" (obviously not available in C99) >in the code an alternative?, or you are suggesting that documenting that constrain >should be done in a comment and hope it doesn't get ignored in the future, or >maybe gets instead made less likely to fail by some additional work, like the one I >suggested to do later by moving this code around and using intmax_t instead? > >not that there are 2 different scenarios which we might seem to be flip flopping >about : > >1) victim gets attacked by tricking them into using the wrong SUDO_UID > >unlikely to be useful as you pointed out, and totally useless if we still restrict this >code to run only as root > >2) attacker using this code to elevate privileges themselves > >only useful if this code is not run as root. > >My concern again, is not with this code AS-IS but how it might be used in the >future. > >> Of course you can tell any user who runs "sudo" to set SUDO_UID to >> 1000 + 64k and cause wrap-around, but then you can tell them to set >> SUDO_UID to 1000 without relying on wrap-around and have the same >> effect. So, let's stop worrying about this bogus scenario. > >bogus only if we are still only running this code as root, of course. > >> As to the "we can break compilation with -Wsign-compare on a system >> with signed uid_t", I agree that is true if we have > >Apologies for not documenting it until now, but I had -Wtautological-constant-out- >of-range-compare in mind instead, but your are correct either one would work >and the point was that (without having to add even an "static assert") we were >able to find them and warn them that they need to patch. > >> env_id <= (uid_t) -1 > >If that was not enough, that simple code ALSO disabled the code in that case to >make sure they MUST patch locally if they need to make it work, or come back to >us to figure out a portable way to accommodate them in the future, with all the >information about their system we currently lack. > >> there. But I am not sure if that is the most effective way to smoke >> out platforms where this code has trouble working correctly. Also, I >> would think that a system with signed uid_t is a possibility, but a >> user with a negative UID? > >It doesn't need to be a real user (specially if someone independently decides to >remove the restriction that keeps this code available only to root). > >The fact that it was negative but was treated as a positive number on our code just >makes the wraparound we decided to ignore before more likely to work without >triggering alarms somewhere else and because we decided to ignore an unlikely to >be useful positive wraparound, we also would fall from the negative wraparound >here that would had protected this code from both if that humble line of code >wouldn't had been removed. > >In your hypothetical system where uid_t is 16-bit (hence 15-bit for valid non- >negative ids if uid_t is signed, since no sane system would have negative ones), >either 65536 or -65536 would become 0, as well as at least the other 2^16 >possibilities that a larger long would provide. > >If the size difference is even smaller (ex: uid_t is signed int), so the type we are >using to parse those values is only 1 bit wider it will still be a concern IMHO. Just to be pedantic uid_t is signed int is not always smaller. It is 32-bit on NonStop. uid_t signed short or signed char would be smaller. I have wondered why uid_t was not defined as unsigned int or unsigned long (although unsigned long is 64 bits on the x86 wide model NonStop) because they cannot be negative. Making assumptions about size or sign when doing this check is not correct IMHO. It should be a direct comparison of env_id != ROOT_UID, where you know what ROOT_UID is on the specific platform. I do not like the <= concept for user id comparison because it is making assumptions. Structurally, on NonStop, (uid & 0x0000FF00) == 0x0000FF00 can be used to check whether the user is in the root group but that is coincidental and subject to change without notice. No one worth their salt does that comparison on platform, rather they compare getgid() == 255 to do that test. > >I know people that wrote code to check if "/" was writable as means to make sure >they were "root", because that is what any sane system would do, and then came >Windows and even in 2022 anyone can write to "/" >there and create subdirectories. On NonStop: / is often writable by non-root users in the root group. Non-root users in the root group sometimes have repositories. In cygwin, / is owned by the user who installed cygwin or the OS rather than root. It is a relatively random number, and definitely not 0. It is also possible that a dedicated VM in Linux can be spun up for sandbox testing allowing anyone to write anywhere. Even if you run git as Administrator on Windows 10+, it will not have the userId of 0 in cygwin git. I do not think the / writable assumption is portable.
Carlo Arenas <carenas@gmail.com> writes: > not that there are 2 different scenarios which we might seem to be > flip flopping about : > > 1) victim gets attacked by tricking them into using the wrong SUDO_UID > > unlikely to be useful as you pointed out, and totally useless if we > still restrict this code to run only as root I think we established that we are not interested in this long ago. > 2) attacker using this code to elevate privileges themselves > > only useful if this code is not run as root. An attacker who is not root would not make the "what does SUDO_UID say about the user we came from?", and "git" will not be setuid binary, so I agree the code is not useful for such an attack, either. > My concern again, is not with this code AS-IS but how it might be used > in the future. I'd rather not such a "concern" to block us for too long. >> Of course you can tell any user who runs "sudo" to set SUDO_UID to >> 1000 + 64k and cause wrap-around, but then you can tell them to set >> SUDO_UID to 1000 without relying on wrap-around and have the same >> effect. So, let's stop worrying about this bogus scenario. > > bogus only if we are still only running this code as root, of course. And this code is only run to learn what SUDO_UID says, which is what we check when we notice geteuid() says we are root. >> As to the "we can break compilation with -Wsign-compare on a system >> with signed uid_t", I agree that is true if we have > > Apologies for not documenting it until now, but I had > -Wtautological-constant-out-of-range-compare in mind instead, but your > are correct either one would work and the point was that (without > having to add even an "static assert") we were able to find them and > warn them that they need to patch. > >> env_id <= (uid_t) -1 > > If that was not enough, that simple code ALSO disabled the code in > that case to make sure they MUST patch locally if they need to make it > work, or come back to us to figure out a portable way to accommodate > them in the future, with all the information about their system we > currently lack. Without a comment to say that, nobody would be able to figure out that we are waiting for them to speak up. /* the code does not work on a system with signed uid */ intmax_t tmp = (uid_t) -1; if (tmp < 0) BUG("report to git@vger that you have a signed uid_t"); or better yet, a compile-time equivalent, perhaps. >> there. But I am not sure if that is the most effective way to smoke >> out platforms where this code has trouble working correctly. Also, >> I would think that a system with signed uid_t is a possibility, but >> a user with a negative UID? > > It doesn't need to be a real user (specially if someone independently > decides to remove the restriction that keeps this code available only > to root). When they break, they can keep both halves. Is it our concern?
diff --git a/Documentation/config/safe.txt b/Documentation/config/safe.txt index 6d764fe0cc..a6b81f6cfc 100644 --- a/Documentation/config/safe.txt +++ b/Documentation/config/safe.txt @@ -26,3 +26,13 @@ directory was listed in the `safe.directory` list. If `safe.directory=*` is set in system config and you want to re-enable this protection, then initialize your list with an empty value before listing the repositories that you deem safe. ++ +When git tries to check for ownership of git repositories, it will +obviously do so with the uid of the user that is running git itself, +but if git is running as root, in a platform that provides sudo and is +not Windows, it will check first if it might have been started through +it, and if that is the case, will instead use the uid of the user that +did invoke that instead. +If that is not what you would prefer and want git to only trust +repositories that are owned by root instead, then you should remove +the `SUDO_UID` variable from root's environment. diff --git a/git-compat-util.h b/git-compat-util.h index 63ba89dd31..409df99463 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -393,12 +393,59 @@ static inline int git_offset_1st_component(const char *path) #endif #ifndef is_path_owned_by_current_user + +#ifdef __TANDEM +#define ROOT_UID 65535 +#else +#define ROOT_UID 0 +#endif + +/* + * this helper function overrides a ROOT_UID with the one provided by + * an environment variable, do not use unless the original user is + * root + * WARNING: this function assumes uid_t is unsigned, if you got here + * because of a warning or a bug will need a patch and would + * be nice if you let us know + */ +static inline void extract_id_from_env(const char *env, uid_t *id) +{ + const char *real_uid = getenv(env); + + /* discard any empty values */ + if (real_uid && *real_uid) { + char *endptr = NULL; + unsigned long env_id; + + errno = 0; + env_id = strtoul(real_uid, &endptr, 10); + /* + * env_id could underflow/overflow in the previous call + * and if it will still fit in a long it will not report + * it as error with ERANGE, instead silently using an + * equivalent positive number that might be bogus. + * if uid_t is narrower than long, it might not fit, + * hence why we need to check it against the maximum + * possible uid_t value before accepting it. + */ + if (!*endptr && !errno && env_id <= (uid_t)-1) + *id = env_id; + } +} + static inline int is_path_owned_by_current_uid(const char *path) { struct stat st; + uid_t euid; + if (lstat(path, &st)) return 0; - return st.st_uid == geteuid(); + + euid = geteuid(); + if (euid == ROOT_UID) + extract_id_from_env("SUDO_UID", &euid); + + return st.st_uid == euid; } #define is_path_owned_by_current_user is_path_owned_by_current_uid diff --git a/t/t0034-root-safe-directory.sh b/t/t0034-root-safe-directory.sh index 2e4492a66d..ecd9dca6b3 100755 --- a/t/t0034-root-safe-directory.sh +++ b/t/t0034-root-safe-directory.sh @@ -29,7 +29,7 @@ test_expect_success SUDO 'setup' ' ) ' -test_expect_failure SUDO 'sudo git status as original owner' ' +test_expect_success SUDO 'sudo git status as original owner' ' ( cd root/r && git status &&
bdc77d1d685 (Add a function to determine whether a path is owned by the current user, 2022-03-02) checks for the effective uid of the running process using geteuid() but didn't account for cases where that user was root (because git was invoked through sudo or a compatible tool) and the original uid that repository trusted for its config was no longer known, therefore failing the following otherwise safe call: guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty [sudo] password for guy: fatal: unsafe repository ('/home/guy/Software/uncrustify' is owned by someone else) Attempt to detect those cases by using the environment variables that those tools create to keep track of the original user id, and do the ownership check using that instead. This assumes the environment the user is running on after going privileged can't be tampered with, and also adds code to restrict that the new behavior only applies if running as root, therefore keeping the most common case, which runs unprivileged, from changing, but because of that, it will miss cases where sudo (or an equivalent) was used to change to another unprivileged user or where the equivalent tool used to raise privileges didn't track the original id in a sudo compatible way. Because of compatibility with sudo, the code assumes that uid_t is an unsigned integer type, but adds additional logic to protect itself against possibly malicious ids outside the expected range and ignore them. A warning should be generated if uid_t is signed and the code would need to be locally patched to work correctly, but this is also a weather balloon of sorts so we will then now which systems those are and whether we should accommodate for their portability in our codebase. Reported-by: Guy Maurel <guy.j@maurel.de> Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Helped-by: Randall Becker <rsbecker@nexbridge.com> Helped-by: Phillip Wood <phillip.wood123@gmail.com> Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> --- Documentation/config/safe.txt | 10 +++++++ git-compat-util.h | 49 +++++++++++++++++++++++++++++++++- t/t0034-root-safe-directory.sh | 2 +- 3 files changed, 59 insertions(+), 2 deletions(-)