Bug 1416044 (CVE-2016-10156)

Summary: CVE-2016-10156 systemd: systemd creates world-writable suid files allowing root privilege escalation
Product: [Other] Security Response Reporter: Adam Mariš <amaris>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED NOTABUG QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: bat.men, johannbg, lnykryn, msekleta, muadda, ssahani, s, systemd-maint-list, systemd-maint, zbyszek
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: systemd 229 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-01-24 13:54:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1416047    

Description Adam Mariš 2017-01-24 13:12:52 UTC
It was found that systemd creates world-writable SUID files that allows local attacker to dump binaries into them and run arbitrary code as root.

This issue affects systemd v228 and was introduced by:

https://github.com/systemd/systemd/commit/ee735086f8670be1591fa9593e80dd60163a7a2f

and fixed by:

https://github.com/systemd/systemd/commit/06eeacb6fe029804f296b065b3ce91e796e1cd0e

Original bug report:

https://bugzilla.novell.com/show_bug.cgi?id=1020601

Comment 1 Zbigniew Jędrzejewski-Szmek 2017-01-24 13:25:57 UTC
Does this apply to any Fedora versions?

Comment 2 Tomas Hoger 2017-01-24 13:48:48 UTC
(In reply to Zbigniew Jędrzejewski-Szmek from comment #1)
> Does this apply to any Fedora versions?

F24 already has 229 and also GAed with 229, AFAICS.  I see 222 was the latest version in F23.  It does not seem any released Fedora version was affected.  Sanity check from you as a package maintainer would definitely be good.

Comment 3 Tomas Hoger 2017-01-24 13:54:52 UTC
systemd in Red Hat Enterprise Linux 7 is not affected - all touch_file() calls use either mode 0 or mode 644.

Comment 4 Adam Mariš 2017-01-24 13:56:46 UTC
Reference:

http://seclists.org/oss-sec/2017/q1/175

Comment 6 Bat.Men 2017-01-24 20:20:33 UTC
(In reply to Tomas Hoger from comment #3)
> systemd in Red Hat Enterprise Linux 7 is not affected - all touch_file()
> calls use either mode 0 or mode 644.

Hello :) does it mean Centos 7 is not affected too ? Thanks

Comment 7 Bat.Men 2017-01-24 22:22:14 UTC
(In reply to Bat.Men from comment #6)
> (In reply to Tomas Hoger from comment #3)
> > systemd in Red Hat Enterprise Linux 7 is not affected - all touch_file()
> > calls use either mode 0 or mode 644.
> 
> Hello :) does it mean Centos 7 is not affected too ? Thanks

I forget to write/mention that i watched into systemd-219-19.el7_2.13.src.rpm and i found in source folder systemd-219\src\shared\util.c the same source line wich had to be patched ...

fd = open(path, O_WRONLY|O_CREAT|O_CLOEXEC|O_NOCTTY, mode > 0 ? mode : 0644);

the .patch files did not contain an update for this line, too. 
So i'm not sure - i'm not a system developer ;)

Comment 8 Adam Mariš 2017-01-25 10:01:52 UTC
(In reply to Bat.Men from comment #7)
> (In reply to Bat.Men from comment #6)
> > (In reply to Tomas Hoger from comment #3)
> > > systemd in Red Hat Enterprise Linux 7 is not affected - all touch_file()
> > > calls use either mode 0 or mode 644.
> > 
> > Hello :) does it mean Centos 7 is not affected too ? Thanks
> 
> I forget to write/mention that i watched into
> systemd-219-19.el7_2.13.src.rpm and i found in source folder
> systemd-219\src\shared\util.c the same source line wich had to be patched ...
> 
> fd = open(path, O_WRONLY|O_CREAT|O_CLOEXEC|O_NOCTTY, mode > 0 ? mode : 0644);
> 
> the .patch files did not contain an update for this line, too. 
> So i'm not sure - i'm not a system developer ;)

systemd-219 doesn't contain the patch that introduced this vulnerability. When you grep the source code for all calls to touch_file, you can see that mode is always set to either 0 or 0644, which means that `mode > 0 ? mode : 0644` will always return 0644, thus no world-writable files are created.