CVE-2017-9445: systemd Hit By New Security Vulnerability

[unixfan2001]

I've explained the multitude of reasons why I don't like systemd (being a textbook example of feature creep, the way they handle bugs and knowingly creating way too big of an attack surface for something that can have catastrophic consequences if compromised to name a few)

[CITATION NEEDED]

systemd PID1 should've a much smaller attack surface than sysvinit.
With sysvinit it's rather easy to cause all sorts of race conditions due to its overly messy nature.

[L_A_G]

[CITATION NEEDED]

systemd PID1 should've a much smaller attack surface than sysvinit.
With sysvinit it's rather easy to cause all sorts of race conditions due to its overly messy nature.

The fact that sysvinint doesn't do a particularly good job at keeping itself safe from attacks trough good development practices doesn't make it acceptable for systemd to cause unnecessary security risks because of equally bad or worse practices. Only children (and the child minded) think that something bad is acceptable because someone else does it.

Seriously, when the developers of an init system decide to add more and more functionality to the point where the only thing missing is a built-in email client it doesn't take an expert to realize something is badly wrong.

[boxie]

well you could stop right there

I could, but let's see where this thought experiment goes.

pdns-recursor has only had a few vulns over the years and would largely fill the role that systemd-resolved does. it is also largely battle tested with a great speed and good reputation.

this is one such example code base that could have been used to build on top of to make resolved.

The main reason I make the argument that going the DIY route was wrong is because when this project was announced, the people who knew what they were doing told the people who had never written a dns resolver before that it was hard, that there were a lot of things that could break and they would be better off not doing it.

well, they ignored that and ended up exactly in the place that they were told they were going to be.

[aht0]

no, we can continue when you name foss dns which solves issues solved by systemd-resolved and does not have vulnerabilities. i'm in good mood today, so you can name two projects each having only one of those properties. and strawman was on your side when you implied that somewhere exists code which systemd people are refusing to use for no particular reason

Seems you have already forgotten what another poster posted. Or prefer to pretend it's not there.
https://lists.dns-oarc.net/pipermail...ne/014964.html

Now, tell me again about the advantages of systemd-resolved. Feels like pretty much anything is better than this thing you defend with a bare chest.

logic is simple: systemd-haters are imbeciles, they "predict" truisms

Reminds me of women. Emotion - "they attack my love-child" is primary. All "logic" revolves around it, rational thinking escaped the home.

i think that might be a tad harsh. they want the features true, but every dev tries their best to do good work. The opportunity to do something new is always a strong pull to DIY, but that gets you into NIH territory.

there have been plenty of times that I would have written something myself - because it was a cool project, only for my boss to say "here, use this existing awesome tool that already does the job"

May sound harsh but is it really? OpenBSD devs follow the philosophy of not allowing a feature/component into RELEASE before it's ready. And it's considered "ready" when it feels like ready (feature complete). Linux could really benefit from similar mental approach, when dealing with critical system components. It's fucking common sense.

The vulnerability just found have nothing to do with the things in that prediction which was ramblings about the binary to xml and back translation that systemd-resolved uses in order to pass the DNS data over D-BUS.

And if any one didn't notice (since it wasn't advertised everywhere due to not being systemd) there where a CVE issued early today for Bind.

Arguable. Actual vulnerability was caused by programming error. Prediction predicted vulnerabilities based on module design. True - literally taken, both are different issues. At certain level though - both, programming errors and faulty design are results of haphazard approach to the whole thing.

Why should I care about bind? When there is BSD-licensed unbound. Just feels odd, because multiple posters have thrown bind and it's vulnerabilities on my face. As a BSD user I can't literally remember when was the last time I had to use bind. Regardless, systemd-resolved and bind are not comparable. The latter is actually functional as DNS server. systemd-resolved still has about 40 open bugs according to systemd's github page where people struggle with basic dns function-related errors.

[unixfan2001]

The fact that sysvinint doesn't do a particularly good job at keeping itself safe from attacks trough good development practices doesn't make it acceptable for systemd to cause unnecessary security risks because of equally bad or worse practices. Only children (and the child minded) think that something bad is acceptable because someone else does it.

Seriously, when the developers of an init system decide to add more and more functionality to the point where the only thing missing is a built-in email client it doesn't take an expert to realize something is badly wrong.

Again with the BS?
None of that is part of PID1.

systemd PID1 has a consistently smaller attack surface than sysvinit.

Can you people please, for the love of god, learn the difference between a piece of software and a project/monorepository that may contain several pieces of software?
Your complaints about systemd are like me complaining about a bug in Thunderbird but referring to it as "Firefox" or "Mozilla".

[aht0]

Bad comparison. While installing Firefox, you do not get Thunderbird forcibly installed along with it..