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]
Date: Wed, 4 Jun 2014 11:13:51 +0200
From: Jose Carlos Luna Duran <jose.carlos.luna@...il.com>
To: oss-security@...ts.openwall.com
Cc: fulldisclosure@...lists.org, bugtraq@...urityfocus.com,
  advisories <advisories@...xperts.de>, bugs@...uritytracker.com
Subject: Re: [oss-security] Bug in bash <= 4.3 [security feature bypassed]

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 as the problem that could be
exploited by that would really be in the original program that does
not drop privs before invoking the shell. This has been known for some
time in some circles at least, but as I said the problem would really
be in the non-priv-dropping privileged program, that's why most people
did not really care that much. Last year there was a vuln that is very
much related to this subject:
http://blog.cmpxchg8b.com/2013/08/security-debianisms.html

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

Therefore setuid calls do not fail anymore even in the case of
existing resource limits for processes (in linux).

But in any case, for the sake of correctness I agree that the
drop_priv code should be fixed (or just completely removed...).

2014-06-03 16:16 GMT+02:00 Hector Marco <hecmargi@....es>:
> Hi everyone,
>
> Recently we discovered a bug in bash. After some time after reporting
> it to bash developers, it has not been fixed.
>
> We think that this is a security issue because in some circumstances
> the bash security feature could be bypassed allowing the bash to be a
> valid target shell in an attack.
>
> We strongly recommend to patch your bash code.
>
> Why don't fix this bug by simple adding mandatory "if" clause ?
> Any comments about this issue are welcomed.
>
>
> Details at:
> http://hmarco.org/bugs/bash_4.3-setuid-bug.html
>
>
>
> Thanks you,
>
> Hector Marco
> http://hmarco.org



-- 
Jose Carlos Luna Duran
Network Software Engineering.
Jose.Carlos.Luna@...il.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ