A while back an old friend had asked me if I had a chfn bug. I could see why he wanted one, I mean, a suid 0 binary on every system? Wow yeah, but sadly no, at the time I did not have one. A couple months went by, and later I was playing around with chsh (a related binary, from the same package, that changes the user’s default shell).
Part 1: chsh
I had about given up, as I wasn’t using a fuzzer and was trying it all by hand; as a last ditch effort
I decided to try adding a user
test1 and doing:
just for shits and gigs (because chsh usually prevents you from changing your shell to something thats not
actually a shell listed in
which edit’s it’s
/etc/passwd reference to show a line like:
Ok. It had more A’s than that. A lot more.
Well damn, that didn’t work, it just gracefully warned me that the file doesn’t even exist… Lets try something else. I gave up.
Part 2: chfn
About a day later I moved on, with the same virtual machine, and decided to play with a
different binary, from the same suite of utilties, also SETUID root,
chsh. First I wondered if it even would
allow me to use non-numeric characters in a phone number feild, specified by
-h, so, like a lazy ass, I used
sudo from my user, thus:
Would do. I got the response:
chfn: user 'test1' does not exist in /etc/passwd …Wait what?
I must have removed the user the other day and forgot about it, I thought.
So I ran:
Also an unexpected:
useradd: user 'test1' already exists
Now what the hell. I now check on
/etc/passwd to figure out what the deal is, and to my surprise, test1 actually
does still exist afterall, and still with that extremely long shell field from the other day! Wow, that’s strange,
it’s actually bugging out with a buffer overflow without crashing. So I thought, I better try this again from the
start, since I haddn’t put it all together yet.
Part 3: userdel
userdel on the account, and get back a similar message:
userdel: user 'test1' does not exist
I think here was when I realized it was all connected, because forgive me, I can be a bit dense at times. After looking the utility up on Github, I realize they are indeed all from the same package…
Killing 3 birds with one stone
…and all call to the same function
pw_locate which in practice looks like:
Which is using:
In the code, called by passwd_parse, but I don’t see that ever being called by what is making the function fail, though I could be wrong.
sgetpwent.c returns 0 on fail, and could be root cause for
NULL being returned later.
NULL instead of
p->eptr when it should not, but I don’t see it ever call
return (void *) sgetpwent (line); so the error still exists with too long of a string. It may be
that returning 0 will always tell it to return NULL when it should not, and this could be the reason a classical
buffer overflow with a segmentation fault is prevented. The other major cavet to this vulnerability, and why
I haven’t released a PoC for it, is that to trigger it, you need to already be root, to be able to edit the
/etc/passwd beyond constraints set by
chfn themselves for a user.