[nolok]

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]

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/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]

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

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.

[bandrami]

If you care about security, you should run the latest version of all the security-critical software you run

Well, pick your poison: the latest version also introduces new vulnerabilities. Lenny users managed to miss out on Heartbleed entirely, for instance.