6 ms·

So it's true what some-of-you'all been saying all along about systemd! ;-D One question: any smell of intentional obfuscation for this vulnerability, or is it

So it's true what some-of-you'all been saying all along about systemd! ;-D One question: any smell of intentional obfuscation for this vulnerability, or is it impossible to tell?

blakesterz 8y ago
>> One question: any smell of intentional obfuscation for this vulnerability, or is it impossible to tell? I always think that anytime there's an interesting bug in ANYTHING. I'm not an expert, but I would think it would be nearly impossible to tell the difference between "someone made a mistake" and "someone made this look like a mistake". I would think any decent programmer with malicious intent could do that anytime they wanted.
dsr_ 8y ago
Here's a thing to ponder: If this were not buried in systemd, but was part of a standalone dhcpd package, would it have been done better or caught earlier? One of the major criticisms of systemd is that it wants to take over all system management functions. In order to do that it needs to offer at least minimally functional versions of all the services it pushes out. It should not be news to anyone that trying to do everything instead of integrating with existing projects leads to sloppiness. This incident is evidence suggesting that other serious issues are lurking in systemd as a result of the actions naturally arising from their policy.
- LukeShu 8y ago
  The problem was in systemd-networkd, not systemd. One of the more popular DHCP clients is 'dhcpcd', which was created and is maintained by Roy Marples, the creator of OpenRC. It's fine when someone wants to work on DHCP clients and init systems, unless that init system is systemd? (And for the record, systemd integrates wonderfully with dhcpcd.)
  - AnthonyMouse 8y ago
    dhcpcd is not solely or even primarily used with OpenRC, it just happens to be created by the same person. What systemd is doing is something else -- not recreating one thing because there is a lack of implementation diversity or the existing implementations are subpar, but reimplementing everything even when there are multiple existing reasonable implementations, just because.
- zzzcpan 8y ago
  Rewriting everything is fine, as long as it's not in C or similar insecure by design programming language, it doesn't invent DSLs on top of INI/YAML/JSON files, uses proper architecture with clearly defined boundaries and protocols, allowing custom application-specific management instead of forcing everyone into author's narrow worldview full of incorrect assumptions. So as long as you are not doing what systemd does. Centralized management/monitoring in general sucks. People don't seem to understand the problem and keep reinventing new centralized architectures suitable for their own special cases, instead of addressing that on architecture level.
  - LukeShu 8y ago
    > doesn't invent DSLs Systemd didn't invent a DSL. It uses the existing config language from D-Bus (whether or not you think that's a good language is another matter). > uses proper architecture with clearly defined boundaries What boundaries in systemd aren't clearly defined? > allowing custom application-specific management What do you mean by this?
- toast0 8y ago
  I'm sure (but don't recall) Redhat's pump and ISC's DHCPCD have had CVEs; we all know BINDs resolver and ntpd had CVEs. If one is going to rewrite all of these things, I would expect one to learn from the history and not make the same mistakes over again.
  - LukeShu 8y ago
    Nit: ISC's DHCP client is 'dhclient', not 'dhcpcd'. 'dhcpcd' is Roy Marple's DHCP client.
  - deialtrous 8y ago
    I would only expect that if the people rewriting everything were good programmers and said they were rewriting it to be secure. Most rewrites are done for non-security reasons are don't improve security.
    - mannykannot 8y ago
      Programmers should give appropriate attention to security regardless of whether they are doing either original work or a rewrite, and in the latter case, regardless of the reasons for the rewrite. I would not regard those who do otherwise as good programmers. Clearly, a DHCPv6 client within Linux' system administration suite is a case where security is an issue of the first magnitude.
      - deialtrous 8y ago
        Programmers should do a lot of things that most of them do not do. The statement was "I would expect..." and I replied that it doesn't make sense to expect those things because the vast majority of programmers don't know or care about security at all. We still see the same trivial SQL injections being written again and again on today's web, often by 20+ year programming "veterans".
- quickben 8y ago
  This approach increases the attack surface because it is included in the most popular distros by default.

So it's true what some-of-you'all been saying all along about systemd! ;-D One question: any smell of intentional obfuscation for this vulnerability, or is it impossible to tell?

blakesterz 8y ago

>> One question: any smell of intentional obfuscation for this vulnerability, or is it impossible to tell? I always think that anytime there's an interesting bug in ANYTHING. I'm not an expert, but I would think it would be nearly impossible to tell the difference between "someone made a mistake" and "someone made this look like a mistake". I would think any decent programmer with malicious intent could do that anytime they wanted.

dsr_ 8y ago

Here's a thing to ponder: If this were not buried in systemd, but was part of a standalone dhcpd package, would it have been done better or caught earlier? One of the major criticisms of systemd is that it wants to take over all system management functions. In order to do that it needs to offer at least minimally functional versions of all the services it pushes out. It should not be news to anyone that trying to do everything instead of integrating with existing projects leads to sloppiness. This incident is evidence suggesting that other serious issues are lurking in systemd as a result of the actions naturally arising from their policy.

LukeShu 8y ago
The problem was in systemd-networkd, not systemd. One of the more popular DHCP clients is 'dhcpcd', which was created and is maintained by Roy Marples, the creator of OpenRC. It's fine when someone wants to work on DHCP clients and init systems, unless that init system is systemd? (And for the record, systemd integrates wonderfully with dhcpcd.)
- AnthonyMouse 8y ago
  dhcpcd is not solely or even primarily used with OpenRC, it just happens to be created by the same person. What systemd is doing is something else -- not recreating one thing because there is a lack of implementation diversity or the existing implementations are subpar, but reimplementing everything even when there are multiple existing reasonable implementations, just because.
zzzcpan 8y ago
Rewriting everything is fine, as long as it's not in C or similar insecure by design programming language, it doesn't invent DSLs on top of INI/YAML/JSON files, uses proper architecture with clearly defined boundaries and protocols, allowing custom application-specific management instead of forcing everyone into author's narrow worldview full of incorrect assumptions. So as long as you are not doing what systemd does. Centralized management/monitoring in general sucks. People don't seem to understand the problem and keep reinventing new centralized architectures suitable for their own special cases, instead of addressing that on architecture level.
- LukeShu 8y ago
  > doesn't invent DSLs Systemd didn't invent a DSL. It uses the existing config language from D-Bus (whether or not you think that's a good language is another matter). > uses proper architecture with clearly defined boundaries What boundaries in systemd aren't clearly defined? > allowing custom application-specific management What do you mean by this?
toast0 8y ago
I'm sure (but don't recall) Redhat's pump and ISC's DHCPCD have had CVEs; we all know BINDs resolver and ntpd had CVEs. If one is going to rewrite all of these things, I would expect one to learn from the history and not make the same mistakes over again.
- LukeShu 8y ago
  Nit: ISC's DHCP client is 'dhclient', not 'dhcpcd'. 'dhcpcd' is Roy Marple's DHCP client.
- deialtrous 8y ago
  I would only expect that if the people rewriting everything were good programmers and said they were rewriting it to be secure. Most rewrites are done for non-security reasons are don't improve security.
  - mannykannot 8y ago
    Programmers should give appropriate attention to security regardless of whether they are doing either original work or a rewrite, and in the latter case, regardless of the reasons for the rewrite. I would not regard those who do otherwise as good programmers. Clearly, a DHCPv6 client within Linux' system administration suite is a case where security is an issue of the first magnitude.
    - deialtrous 8y ago
      Programmers should do a lot of things that most of them do not do. The statement was "I would expect..." and I replied that it doesn't make sense to expect those things because the vast majority of programmers don't know or care about security at all. We still see the same trivial SQL injections being written again and again on today's web, often by 20+ year programming "veterans".
quickben 8y ago
This approach increases the attack surface because it is included in the most popular distros by default.