bugtraq - Re: [FD] [oss-security] Bug in bash <= 4.3 [security feature bypassed]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20140605080301.B31568005A@notatla.org.uk>
Date: Thu, 05 Jun 2014 09:03:01 +0100
From: lists@...atla.org.uk
To: oss-security@...ts.openwall.com, jose.carlos.luna@...il.com
Cc: fulldisclosure@...lists.org, bugtraq@...urityfocus.com,
  bugs@...uritytracker.com
Subject: Re: [FD] [oss-security] Bug in bash <= 4.3 [security feature
 bypassed]

Jose Carlos Luna Duran writes:

> In my opinion the drop of privs in bash was mostly a "help" measure
> for poorly written setuid programs executing system() calls. I don't
> think is the role of bash to do this ...

True, but it is a slight help and I'm in favour of keeping it.

> Correct me if I'm wrong, but even in that case there is another "help"
> measure that has been implemented at least in linux kernels > 3.1:
> http://lxr.free-electrons.com/source/kernel/sys.c?v=3.1#L628

For permanent dropping of privilege I suggest calling setgid() and
setuid() to the desired values *twice* (and ignore the return code).
Then try to reset to the original values (should fail; ignore return code).

Then test that the real and effective values are the same and are the
ones you want - that's the result that indicates success in this case.
And exit() if failed.

That's the simple usage guide - David Wagner has written at length on
the technicalities.