7 ms·

>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'

by implr 10y ago

>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.

galapago 10y ago
> they also seem to think that a local DoS is not enough for a CVE Some vendors do not consider local DoS as security issues. I tried to discuss these kind of issues in oss-security but even MITRE refused to assign a CVE.
- belorn 10y ago
  If the system are not restricted by having quota on every computer resource its trivial for any local user to DoS the system. For the issue to be exploitable, you need to have restrictions in place and to my knowledge the only way to do so in the past was with seLinux. Today of course there is cgroup.
- kseifried 10y ago
  Which one was this specifically? Not all local DoS's are security vulnerabilities, in general there needs to be a trust boundary that is violated, e.g. the ping of death, clearly a single remote ICMP packet shouldn't cause the system to reboot. But what about DoS's that can only be triggered by root? And the whole grey area in between these two extremes?
  - galapago 10y ago
    It was a trivial DoS using a SVG file in a browser. After a a minute, it consumes most of the memory available.
throwawayish 10y ago
I'm not aware of server or desktop OS that isn't generally vulnerable to local DoS.
- angry_octet 10y ago
  OT: If you're averaging +24 karma per day from a throwaway account, maybe you don't need a throwaway?
  - delta1 10y ago
    That's why it's only throwaway"ish" ;)
    - angry_octet 10y ago
      Given how furiously the thought police react to an OT comment, or indeed any comment mentioning karma, I should have created a throwaway for that question... -4 jeez
- SixSigma 10y ago
  https://en.wikipedia.org/wiki/Burroughs_large_systems https://en.wikipedia.org/wiki/Burroughs_large_systems
- dandelion_lover 10y ago
  Qubes OS
  - throwawayish 10y ago
    As a Qubes user, no, not at all. It's fairly easy to starve other VMs of resources. Qubes is more vulnerable here than other systems, due to it's dynamic allocation of memory. A VM that has a no-matter-what fixed limit of say 2 GB RAM would have a harder time to cause trouble there, but the dynamic management done by Qubes is a major selling point, otherwise it wouldn't be really practical to use on mobile hardware (which is all the rage). I believe one can disable it on a per-VM basis though, so there's that.
    - dandelion_lover 10y ago
      As a Qubes OS user, yes, you can disable the dynamic memory allocation for chosen VMs. So I do not see the problem. Upd: right click in Qubes Manager, VM settings, Advanced, Include in memory balancing, remove the tick. And you can even choose how many CPU cores a VM can use.
KuiN 10y ago
This is the really concerning part. silently fixed in the upstream git is not at all an acceptable way to deal with serious security flaws in your product.
- grhmc 10y ago
  This is frequently how the linux kernel operates.
  - ungamed 10y ago
    The distro vendors are the ones who frequently pull apart commit logs to be documented.
  - sounds 10y ago
    It is not done silently - lack of a public announcement is not the same thing as radio silence. (For CVEs affecting the linux kernel)
  - gshulegaard 10y ago
    Just to be clear, systemd is not part of the Linux kernel. Also, if you are going to make a broad claim like that I would appreciate some citations/examples. I have no idea if you are wrong or right on the whole, but without examples I can't learn myself.
    - kuschku 10y ago
      See for example here: https://news.ycombinator.com/item?id=13472329 https://news.ycombinator.com/item?id=13472329
    - kasabali 10y ago
      > if you are going to make a broad claim like that I would appreciate some citations/examples It's a common knowledge for people who are familiar with linux kernel development procedures. For starters you can search for two examples off the top of my head, "dirt cow" , "masturbating monkeys" or gregkh tty vulnerability. I'm sure you'll find dozens of other examples if you are sincere in your interest.
jsmeaton 10y ago
Hanlon's Razor; perhaps whoever wrote/merged the patch didn't consider the possibility of an exploit?
- nolok 10y ago
  I'm not the one who downvoted you, but there is two reasons why this is not a sufficient explanation: 1. That's why you should assign a CVE even for "lower" exploit. This way, people who work in that field look at it and can figure out it's worse when it is. 2. That is still a terrible mark on systemd's procedures that such a thing is not reviewed by someone who will consider an exploit through all lenses, and added with the no-CVE issue from above it makes it even worse. When systemd is taking over more and more critical parts of the system, and getting deployed to most linux distros, it's only fair that we expect more of them and put them under more scrutiny. That they trip on such a "trivial" case is kind of scary.
  - jsmeaton 10y ago
    I mostly agree, but I meant to direct my previous comment to this: > silently fixed in the upstream git is not at all an acceptable way to deal with serious security flaws in your product. I was suggesting that it might not have been silently fixed, and was instead misdiagnosed. You can see the commit here: https://github.com/systemd/systemd/commit/06eeacb6fe029804f296b065b3ce91e796e1cd0e https://github.com/systemd/systemd/commit/06eeacb6fe029804f2... Now I'm not sure if this was linked to a pull request or some other place where discussion took place, but it looks like it was a simple fix, by one person, over a year ago. At a minimum I think this suggests that more scrutiny is required, especially for bugs that suggest security issues.
  - geofft 10y ago
    > 1. That's why you should assign a CVE even for "lower" exploit. This way, people who work in that field look at it and can figure out it's worse when it is. This isn't reliable; exploits aren't obvious. https://www.usenix.org/legacy/event/hotos09/tech/full_papers/arnold/arnold_html/impact.html https://www.usenix.org/legacy/event/hotos09/tech/full_papers... Within a few hours of review of the bug-fix patches affecting Linux kernel version 2.6.24, we identified a commit from February 2008 with serious security consequences (Git ID 7e3c396, commit subject ``sys_remap_file_pages: fix ->vm_file accounting''). At the time that we conducted this review, this bug and its corresponding patch had been disclosed for more than 10 months, yet it had no associated CVE number or record of any security consequences. We developed a privilege escalation exploit for this bug in a few hours; doing so did not require any innovative techniques or extensive expertise. The exploit allows any user on a vulnerable system to gain full administrator privileges on the system. If you care about security, you should run the latest version of all the security-critical software you run. Healthy projects clean up bad / smelly code all the time, and don't investigate the security weaknesses of old versions of their code.
bkor 10y ago
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 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 bugs instead of figuring out if it is a security bug (=method Linus uses).
- berdario 10y ago
  I don't know any insider, but obtaining a CVE was not really difficult: http://seclists.org/oss-sec/2016/q3/231 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 such a close system as you seem to imply (OTOH, obviously CVE cannot guarantee or pretend to have universal coverage of every security issue ever existed) I generally like systemd, but it's irresponsible to not publicly communicate about such an issue if you're aware that it's actually a security issue fix bugs before investigating, that's ok... but not communicating it means that you'll leave users downstream exposed to it, since it won't prompt maintainers to ship the patch/upgrade
  - jwilk 10y ago
    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.
  - bkor 10y ago
    If you go to https://cve.mitre.org/ https://cve.mitre.org/ it has a link "Request a CVE ID" which IMO explains that it is only for some products, not all. Alternatively there's also a weblink below it which want GPG key, etc. Alternatively you can email some mailing list, but I don't see where this is documented. The complaint was that the CVE should've 1) been included in the commit 2) been made. IMO the entire thing is confusing. Also like to repeat: it's super nice that things are reported and have a CVE. But that doesn't mean every security commit will be seen as related to security. I'm pretty sure I've seen enough interesting commits in gdk-pixbuf: https://git.gnome.org/browse/gdk-pixbuf/commit/?id=49dcd2d58ec3695f858c1db003851bd944a14f05 https://git.gnome.org/browse/gdk-pixbuf/commit/?id=49dcd2d58...
ioquatix 10y ago
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-December/038025.html https://lists.freedesktop.org/archives/systemd-devel/2016-De... systemd is a bomb waiting to go off, IMHO.
- papey 10y ago
  Polkit is not linked to system so...
- scrollaway 10y ago
  > polkit, the systemd replacement of sudo I honestly do not understand how you can feel comfortable making judgement calls about projects when you cannot even accurately state their function.
  - gravypod 10y ago
    "Polkit (formerly PolicyKit) is a component for controlling system-wide privileges in Unix-like operating systems." Calling it the sudo for UIs seems reasonable. It lets you manage the permission level of the UI you're using. Does it do something else?
    - lordlimecat 10y ago
      Youre being too generous. GP's statement was, "Did you know that polkit, the systemd replacement of sudo," He calls it a replacement of sudo which is is definitely not.
      - ioquatix 10y ago
        Uh, so, systemd don't recommend to use `sudo systemctl start blah`. Their idea is to use `systemctl start blah` and have polkit handle the authentication. Not sure what's unclear here.
        10y ago
ioquatix 10y ago
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-December/038025.html https://lists.freedesktop.org/archives/systemd-devel/2016-De... systemd is a bomb waiting to go off, IMHO.

by implr 10y ago

galapago 10y ago

> they also seem to think that a local DoS is not enough for a CVE Some vendors do not consider local DoS as security issues. I tried to discuss these kind of issues in oss-security but even MITRE refused to assign a CVE.

belorn 10y ago
If the system are not restricted by having quota on every computer resource its trivial for any local user to DoS the system. For the issue to be exploitable, you need to have restrictions in place and to my knowledge the only way to do so in the past was with seLinux. Today of course there is cgroup.
kseifried 10y ago
Which one was this specifically? Not all local DoS's are security vulnerabilities, in general there needs to be a trust boundary that is violated, e.g. the ping of death, clearly a single remote ICMP packet shouldn't cause the system to reboot. But what about DoS's that can only be triggered by root? And the whole grey area in between these two extremes?
- galapago 10y ago
  It was a trivial DoS using a SVG file in a browser. After a a minute, it consumes most of the memory available.

throwawayish 10y ago

I'm not aware of server or desktop OS that isn't generally vulnerable to local DoS.

angry_octet 10y ago
OT: If you're averaging +24 karma per day from a throwaway account, maybe you don't need a throwaway?
- delta1 10y ago
  That's why it's only throwaway"ish" ;)
  - angry_octet 10y ago
    Given how furiously the thought police react to an OT comment, or indeed any comment mentioning karma, I should have created a throwaway for that question... -4 jeez
SixSigma 10y ago
https://en.wikipedia.org/wiki/Burroughs_large_systems https://en.wikipedia.org/wiki/Burroughs_large_systems
dandelion_lover 10y ago
Qubes OS
- throwawayish 10y ago
  As a Qubes user, no, not at all. It's fairly easy to starve other VMs of resources. Qubes is more vulnerable here than other systems, due to it's dynamic allocation of memory. A VM that has a no-matter-what fixed limit of say 2 GB RAM would have a harder time to cause trouble there, but the dynamic management done by Qubes is a major selling point, otherwise it wouldn't be really practical to use on mobile hardware (which is all the rage). I believe one can disable it on a per-VM basis though, so there's that.
  - dandelion_lover 10y ago
    As a Qubes OS user, yes, you can disable the dynamic memory allocation for chosen VMs. So I do not see the problem. Upd: right click in Qubes Manager, VM settings, Advanced, Include in memory balancing, remove the tick. And you can even choose how many CPU cores a VM can use.

KuiN 10y ago

This is the really concerning part. silently fixed in the upstream git is not at all an acceptable way to deal with serious security flaws in your product.

grhmc 10y ago
This is frequently how the linux kernel operates.
- ungamed 10y ago
  The distro vendors are the ones who frequently pull apart commit logs to be documented.
- sounds 10y ago
  It is not done silently - lack of a public announcement is not the same thing as radio silence. (For CVEs affecting the linux kernel)
- gshulegaard 10y ago
  Just to be clear, systemd is not part of the Linux kernel. Also, if you are going to make a broad claim like that I would appreciate some citations/examples. I have no idea if you are wrong or right on the whole, but without examples I can't learn myself.
  - kuschku 10y ago
    See for example here: https://news.ycombinator.com/item?id=13472329 https://news.ycombinator.com/item?id=13472329
  - kasabali 10y ago
    > if you are going to make a broad claim like that I would appreciate some citations/examples It's a common knowledge for people who are familiar with linux kernel development procedures. For starters you can search for two examples off the top of my head, "dirt cow" , "masturbating monkeys" or gregkh tty vulnerability. I'm sure you'll find dozens of other examples if you are sincere in your interest.

jsmeaton 10y ago

Hanlon's Razor; perhaps whoever wrote/merged the patch didn't consider the possibility of an exploit?

nolok 10y ago
I'm not the one who downvoted you, but there is two reasons why this is not a sufficient explanation: 1. That's why you should assign a CVE even for "lower" exploit. This way, people who work in that field look at it and can figure out it's worse when it is. 2. That is still a terrible mark on systemd's procedures that such a thing is not reviewed by someone who will consider an exploit through all lenses, and added with the no-CVE issue from above it makes it even worse. When systemd is taking over more and more critical parts of the system, and getting deployed to most linux distros, it's only fair that we expect more of them and put them under more scrutiny. That they trip on such a "trivial" case is kind of scary.
- jsmeaton 10y ago
  I mostly agree, but I meant to direct my previous comment to this: > silently fixed in the upstream git is not at all an acceptable way to deal with serious security flaws in your product. I was suggesting that it might not have been silently fixed, and was instead misdiagnosed. You can see the commit here: https://github.com/systemd/systemd/commit/06eeacb6fe029804f296b065b3ce91e796e1cd0e https://github.com/systemd/systemd/commit/06eeacb6fe029804f2... Now I'm not sure if this was linked to a pull request or some other place where discussion took place, but it looks like it was a simple fix, by one person, over a year ago. At a minimum I think this suggests that more scrutiny is required, especially for bugs that suggest security issues.
- geofft 10y ago
  > 1. That's why you should assign a CVE even for "lower" exploit. This way, people who work in that field look at it and can figure out it's worse when it is. This isn't reliable; exploits aren't obvious. https://www.usenix.org/legacy/event/hotos09/tech/full_papers/arnold/arnold_html/impact.html https://www.usenix.org/legacy/event/hotos09/tech/full_papers... Within a few hours of review of the bug-fix patches affecting Linux kernel version 2.6.24, we identified a commit from February 2008 with serious security consequences (Git ID 7e3c396, commit subject ``sys_remap_file_pages: fix ->vm_file accounting''). At the time that we conducted this review, this bug and its corresponding patch had been disclosed for more than 10 months, yet it had no associated CVE number or record of any security consequences. We developed a privilege escalation exploit for this bug in a few hours; doing so did not require any innovative techniques or extensive expertise. The exploit allows any user on a vulnerable system to gain full administrator privileges on the system. If you care about security, you should run the latest version of all the security-critical software you run. Healthy projects clean up bad / smelly code all the time, and don't investigate the security weaknesses of old versions of their code.

bkor 10y ago

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 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 bugs instead of figuring out if it is a security bug (=method Linus uses).

berdario 10y ago
I don't know any insider, but obtaining a CVE was not really difficult: http://seclists.org/oss-sec/2016/q3/231 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 such a close system as you seem to imply (OTOH, obviously CVE cannot guarantee or pretend to have universal coverage of every security issue ever existed) I generally like systemd, but it's irresponsible to not publicly communicate about such an issue if you're aware that it's actually a security issue fix bugs before investigating, that's ok... but not communicating it means that you'll leave users downstream exposed to it, since it won't prompt maintainers to ship the patch/upgrade
- jwilk 10y ago
  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.
- bkor 10y ago
  If you go to https://cve.mitre.org/ https://cve.mitre.org/ it has a link "Request a CVE ID" which IMO explains that it is only for some products, not all. Alternatively there's also a weblink below it which want GPG key, etc. Alternatively you can email some mailing list, but I don't see where this is documented. The complaint was that the CVE should've 1) been included in the commit 2) been made. IMO the entire thing is confusing. Also like to repeat: it's super nice that things are reported and have a CVE. But that doesn't mean every security commit will be seen as related to security. I'm pretty sure I've seen enough interesting commits in gdk-pixbuf: https://git.gnome.org/browse/gdk-pixbuf/commit/?id=49dcd2d58ec3695f858c1db003851bd944a14f05 https://git.gnome.org/browse/gdk-pixbuf/commit/?id=49dcd2d58...

ioquatix 10y ago

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-December/038025.html https://lists.freedesktop.org/archives/systemd-devel/2016-De... systemd is a bomb waiting to go off, IMHO.

papey 10y ago
Polkit is not linked to system so...
scrollaway 10y ago
> polkit, the systemd replacement of sudo I honestly do not understand how you can feel comfortable making judgement calls about projects when you cannot even accurately state their function.
- gravypod 10y ago
  "Polkit (formerly PolicyKit) is a component for controlling system-wide privileges in Unix-like operating systems." Calling it the sudo for UIs seems reasonable. It lets you manage the permission level of the UI you're using. Does it do something else?
  - lordlimecat 10y ago
    Youre being too generous. GP's statement was, "Did you know that polkit, the systemd replacement of sudo," He calls it a replacement of sudo which is is definitely not.
    - ioquatix 10y ago
      Uh, so, systemd don't recommend to use `sudo systemctl start blah`. Their idea is to use `systemctl start blah` and have polkit handle the authentication. Not sure what's unclear here.
      - 10y ago

ioquatix 10y ago