Live data from Hacker News

Systemd v228 local root exploit

openwall.com

31–40 of 162 posts

Re: Systemd v228 local root exploit

#31

Earlier quoted context omitted.

If you are on a systemd system, you can check your version with $ init --version systemd 231 +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS -ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN

Despite being in the man page, the flag --version didn't work for me on Ubuntu 16.04 (various different installations): $ init --version init: unrecognised option '--version' systemd --version works though: $ systemd --version systemd 229

Same on Debian Jessie.

EDIT: And on openSUSE Tumbleweed

Re: Systemd v228 local root exploit

#32
post #26

here's the fix: https://github.com/systemd/systemd/commit/06eeacb6fe029804f2... questions to the local experts: 1) would using a differently designed open() api prevent the issue? 2) would not using C to write systemd prevent the issue? specifically, would using rust, ocaml, ats or ada prevent the issue?

2) maybe. mode_t is unsigned and MODE_INVALID was defined as: #define MODE_INVALID ((mode_t) -1) and the problem was in a check: fd = open(path, O_WRONLY|O_CREAT|O_CLOEXEC|O_NOCTTY, mode > 0 ? mode : 0644); so maybe the author thought MODE_INVALID the other thing is maybe in a safe language you would use an Option/Maybe type here instead of a plain mode_t type.

> maybe safe languages will let you do this explicit cast as well

They will let you, but explicit casts are a red flag in code review.

Re: Systemd v228 local root exploit

#33
post #14

Earlier quoted context omitted.

You're right. Ever since distros made systemd default, computers all over the world have been catching fire, exploding, shooting jets of lava from their headphone jacks. It's the end times

I think the headphone jack lava is more a pulseaudio bug

I personally vote for it as a feature, makes nice effect on my desk. Little WOW effect for colleagues.

Re: Systemd v228 local root exploit

#34
post #25

Earlier quoted context omitted.

CVE is an invite only system, applied to just a few projects. See e.g. https://cve.mitre.org/cve/data_sources_product_coverage.html . Generally you need to know someone to get such an id. If you have a bug in some github project you cannot request a CVE for that. If a CVE is reported you'd usually include that in the commit. But that's not the same as every security bug should have a CVE. Often way easier to just fix…

I don't know any insider, but obtaining a CVE was not really difficult: http://seclists.org/oss-sec/2016/q3/231 (and it was not even my project... I just reported the bug) Now the workflow changed a bit, in the link that you shared in fact it says "For open source software products not listed below, request a CVE ID through the Distributed Weakness Filing Project CNA." which is just an easy-to-fill Google form. Not s…

I don't believe the workflow has changed. CVE for public security issues in free software should be requested on oss-security.

And even if you don't care about the CVE business, posting to oss-sec about your bugs is the right thing to do.

Re: Systemd v228 local root exploit

#35

Earlier quoted context omitted.

If you are on a systemd system, you can check your version with $ init --version systemd 231 +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS -ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN

Despite being in the man page, the flag --version didn't work for me on Ubuntu 16.04 (various different installations): $ init --version init: unrecognised option '--version' systemd --version works though: $ systemd --version systemd 229

systemctl --version on Fedora

Re: Systemd v228 local root exploit

#36
post #14

yeah, awesome, i enjoy this systemD shit show. Linux is so doomed.

You're right. Ever since distros made systemd default, computers all over the world have been catching fire, exploding, shooting jets of lava from their headphone jacks. It's the end times

The reason for Apple removing the headphone jack is finally revealed!

Re: Systemd v228 local root exploit

#37

Earlier quoted context omitted.

If you are on a systemd system, you can check your version with $ init --version systemd 231 +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS -ACL +XZ -LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD -IDN

Despite being in the man page, the flag --version didn't work for me on Ubuntu 16.04 (various different installations): $ init --version init: unrecognised option '--version' systemd --version works though: $ systemd --version systemd 229

Same on Mint 18

Re: Systemd v228 local root exploit

#38
post #25
post #4

>We would like to see that systemd upstream retrieves CVE's themself for their own bugs, even if its believed that its just a local DoS. So not only they didn't notice this was exploitable, they also seem to think that a local DoS is not enough for a CVE or a public report. Excellent.

CVE is an invite only system, applied to just a few projects. See e.g. https://cve.mitre.org/cve/data_sources_product_coverage.html . Generally you need to know someone to get such an id. If you have a bug in some github project you cannot request a CVE for that. If a CVE is reported you'd usually include that in the commit. But that's not the same as every security bug should have a CVE. Often way easier to just fix…

Yes you can. You report it on oss-security mailing list and request a CVE and one will be assigned to you.

Re: Systemd v228 local root exploit

#39
post #4

>We would like to see that systemd upstream retrieves CVE's themself for their own bugs, even if its believed that its just a local DoS. So not only they didn't notice this was exploitable, they also seem to think that a local DoS is not enough for a CVE or a public report. Excellent.

Did you know that polkit, the systemd replacement of sudo, uses JavaScript to validate permissions?

This was the response: https://lists.freedesktop.org/archives/systemd-devel/2016-De...

systemd is a bomb waiting to go off, IMHO.

Re: Systemd v228 local root exploit

#40
post #4

>We would like to see that systemd upstream retrieves CVE's themself for their own bugs, even if its believed that its just a local DoS. So not only they didn't notice this was exploitable, they also seem to think that a local DoS is not enough for a CVE or a public report. Excellent.

Did you know that polkit, the systemd replacement of sudo, uses JavaScript to validate permissions?

This was the response: https://lists.freedesktop.org/archives/systemd-devel/2016-De...

systemd is a bomb waiting to go off, IMHO.

Post reply on HN