Date: Thu, 6 Jul 2017 09:57:25 +0100 From: Ben Tasker <ben@...tasker.co.uk> To: oss-security@...ts.openwall.com Subject: Re: systemd fails to parse user that should run service On Wed, Jul 5, 2017 at 10:58 PM, Simon McVittie <smcv@...ian.org> wrote: > > Not every bug is a security vulnerability (not even the really bad > ones). At the moment, there is a strong correlation between security > vulnerabilities with CVE IDs, and issues for which there is consensus > among relevant upstream and downstream developers that the issue is in > fact a vulnerability for which a prompt security update is necessary. I'm > becoming concerned that if the working definition of a vulnerability > gets stretched too far towards things that are "just a bug", it will > reduce the perceived importance of fixing CVEs promptly, harming the > overall level of security in software. > > Whilst I agree with you in the general sense on this, I'm not sure it's applicable to this particular issue. If this issue is triggered, then a process will run with substantially elevated privileges compared to those that would be expected based on a review of the unit file (or indeed, the installing package). For some distro's, it might stand out immediately as a mistake (as they also prohibit usernames beginning with a digit), but for others (EL7 is referenced in the Github issue) it won't, because the username is considered valid. So, as a result, you've potentially got a daemon listening for connections from the outside world, whilst running as root (despite the fact you're expecting it to run as an unprivileged user). If someone can convince that daemon to run arbitrary code, it does so with superuser privileges. IMHO the discussion on how that unit file makes it onto the system in the first place is an irrelevant distraction. Mistakes happen, whether that's a package reviewer missing the connotations of the *valid* username in the unit file, or some eejit leaving a unit file world writeable (I've seen kernel modules with 0777 on public facing production systems in the past). There is, of course, all kinds of other nastiness you could do in the case of the latter, but the issue in SystemD contributes a nice subtle means to gain root privileges without changing anything too much (reducing the risk of subsequent detection). It may depend on additional prior mistakes, but there's a lot you could potentially do with this, and unless you know to look for it, it's not going to be particularly easy to detect. Assuming it's safe (for a given measure of) because it needs other mistakes to happen, is, at best, unwise. So personally, I'd argue that this is more than "just a bug" as there *are* real-world security connotations to it, and issuing CVE's for issues that require something else to be exploited first isn't a new concept. > On Wed, 05 Jul 2017 at 13:27:17 -0700, Alan Coopersmith wrote: > > Honestly, given the level of flaming and trolling that happens on issues > > like this, locking the report is the only sane option I can see once > > everyone started piling on. Forcing FOSS maintainers to accept infinite > > amounts of shitposting is a horrible way to reduce security by burning > > out all FOSS maintainers quickly and leaving software abandoned. > > I have little to add to this, but I couldn't resist a "me too" here, > because I think Alan's point is very important. Maintainers can't be > expected to behave in a professional and effective way if their working > environment is consistently hostile. > > +1 And in their defence, I would add that SystemD, for various reasons, does attract a lot of vitriol. I'm sure a good chunk of it is perceived as well-deserved by those directing it, but the knock on effect is that other issues wind up getting locked far earlier than they perhaps should (IMO). -- Ben Tasker https://www.bentasker.co.uk
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ