
Systemd (PID1) crash with specially crafted D-Bus message - dijit
https://seclists.org/oss-sec/2019/q1/140
======
saagarjha
> allocates a buffer on the stack

> the length of this is attacker controlled

This isn't the first time this has happened
([https://www.openwall.com/lists/oss-
security/2019/01/09/3](https://www.openwall.com/lists/oss-
security/2019/01/09/3)). Uninformed opinion, but can we just like not stack
allocate things, especially if their size is attacker-controlled? Linux has
already moved away from VLAs for security reasons, I don't see why systemd
shouldn't either.

~~~
userbinator
The critical point is _unboundedly_ attacker-controlled sizes. A reasonable
limit, specified and then carried into the implementation, would've prevented
this bug easily.

Speaking of limits, this is something that I think deserves more attention in
education --- does the algorithm or code you create work for _all_ inputs,
especially those at the limits? Are you even able to determine those limits?
Why does a path in D-Bus need to have a 32-bit length? Is 16 (64K) or even 8
(255) bits sufficient? If not, why? Can it be made sufficient?

Asking the important questions, learning, and understanding is ultimately
going to be a far more useful than the current "just cut off the limb"
attitude toward security that seems so prevalent today. Those questions
should've all been asked and clearly answered at the design stage.

~~~
saagarjha
Rather, I'd say the critical points are that systemd has critical issues it
absolutely should not be having, with the state of tooling we have today
(taint analysis, heck, even a good linter might have been able to find this!).
When the last thing came out someone I know told me that they had just glanced
through the codebase and were not surprised that it had bugs like this; I
think his exact words were something like "you don't have code like this in
_2019_ ".

------
teddyh
This is a month old, and fixes for all major distributions have long since
been released:

[https://security-tracker.debian.org/tracker/CVE-2019-6454](https://security-
tracker.debian.org/tracker/CVE-2019-6454)

------
kevin_thibedeau

        do {
        =>              char prefix[pl+1];
    

Who do we git blame for this turd? Why hasn't their static analysis tooling
found this?

~~~
saagarjha
Take a guess, or don't:
[https://github.com/systemd/systemd/commit/7286037fd438e93137...](https://github.com/systemd/systemd/commit/7286037fd438e93137571fa68a741cc894d8e549)

~~~
esjeon
B.e.a.utiful.

I mean, he is a good programmer, but I’ve seen him (even in other projects)
optimizing codes prematurely, which allows vulnerabilities to slip in. I
understand the temptation, but many of his projects are mostly not performance
critical. Not a good habit.

~~~
kevin_thibedeau
This isn't an optimization. It is pretending that C is like managed code and
using the stack as a glorified garbage collector to avoid the responsibility
of freeing memory. He did the same with his alloca() misuse. I would hope that
they turn on -Wvla to find any more of these landmines.

------
userbinator
_which results in the stack pointer moving outside of the bounds of the
currently mapped stack region, jumping over the stack guard pages._

They don't generate stack probes? I'm used to this behaviour on Windows, where
the compiler will generate code to explicitly touch the guard pages if it
knows/suspects you may allocate more than a page:

[https://geidav.wordpress.com/tag/stack-
probing/](https://geidav.wordpress.com/tag/stack-probing/)

Yes, I know if you try to get it to allocate too much it will still crash, but
that would be an "out of stack" error, so I'm a little surprised at that
description.

~~~
caf
Depends on the compiler and compiler options. For GCC:

[https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-
Options.h...](https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-
Options.html#index-fstack-clash-protection)

