System Down: A systemd-journald exploit

https://www.openwall.com/lists/oss-security/2019/01/09/3

by gmueckl • 8 years ago

385 341 8 years ago

gmueckl4• 8 years ago

These are three long standing exploitable bugs in systemd's journald which can be used to gain local root privileges. Most systemd based distributions are vulnerable and, from the looks of it, may have been for years.

nightfly• 8 years ago

link?

mgalgs• 8 years ago

I believe he's giving a synopsis of TFA

insertcredit14• 8 years ago

I refuse to use systemd to this day. It's unbelievably complex and became established through political power play rather than any sort of merit. Which is without a doubt not what I expected to see in the Linux ecosystem.

isatty• 8 years ago

I do too, for personal use (OpenRC on Gentoo user through and through), but due to the adoption of systemd by popular distributions I don’t see an alternative for work. Unfortunately.

geggam12• 8 years ago

I moved all my personal things to OpenBSD due to the Linux community move away from unix standards

toast03• 8 years ago

If you've got the career capital, move somewhere that doesn't use it? Look for places that run servers on FreeBSD, perhaps.

yjftsjthsd-h• 8 years ago

Yeah, it's not so terrible technically, but politically I despise it. Especially when the people involved take a stance of "we're not actually going to discuss this or debate why this might be the best way to do it, we're just going to slowly try to make your life harder and harder until you give in" ( https://lists.freedesktop.org/archives/systemd-devel/2010-Se... )

craigsmansion• 8 years ago

If it's not technically terrible, it's not technically terrible anymore.

All the initial "ooh and aah" factor of SystemD came from using the kernel's cgroups mechanism, which was a dumpster fire by itself--something dropped by google in the kernel for easier maintenance with the understanding that no one should be stupid enough to use it for something important...enter SystemD.

Apparently cgroups is in better nick these days (as is SystemD), but until the likes of Al Viro come around and give it a clean bill of health, I think I'll pass.

krageon• 8 years ago

It is terrible technically. It does too many things (for no apparent reason) and it's every other month that we see some enormous exploit for it.

siffland3• 8 years ago

Systemd is a double edged sword. I started using FreeBSD in 1999, and Mandrake Linux in 2000ish. I switched to gentoo when it came out, because i like to tinker and see how things work (like or hate the distro it does make you learn a quite a bit).

Fast forward to 2018 and i manage around 500 Redhat servers here. About 150 are at RHEL7 (the others need to be upgraded). So learning systemd is a requirement, it is not going away. I like some points of it. I do like the jounrnalctl command and the ease of looking at logs, however being the hypocrite i am i despise the binary logs and non compatibility with most syslogging devices (i have had to explain lost logs during an audit with systemd and it was not pleasant).

From a end user standpoint systemd is great for my desktop. For the servers it is functional, server boot time does not matter to most administrators. On VM's both boot fast enough, on bare metal....some of our large servers take 5 to 7 minutes to post (thanks HP) so the OS taking 20 to 30 seconds longer to boot is not a big deal.

I follow the systemd mailing list to see what is going on, i think if the guys over there were not as abrasive in some of their answers things would be smoother, and more receptive to the needs of some of the users. I see a lot of features that are desktop specific and that seems to be where their development lies for the most part, desktops and servers are two different beasts.

I guess the infighting just sucks, i am not a fan of systemd simply because i like a simple OS with minimal features to accomplish my objectives, however it is here to stay and i am a Linux Admin so it is part of my job and i learned to use it and keep up with development.

I still use FreeBSD for all my home servers (except my docker swarm), old habits die hard.

brobdingnagians2• 8 years ago

Sounds like a petty dictator pushing everyone to think and act the same; manipulating people until they give in because it takes too much effort to resist. He should consider a career in politics... I always get uncomfortable when I know people who pull stunts like that in RL and it is irritating when it dramatically affects an otherwise very good operating system. I use Void Linux just to avoid systemd, considering its long track record of horrific bugs and security issues.

kokada• 8 years ago

This is not true. systemd did standard multiple interfaces in Linux ecosystem. It is much easier to get things working nowadays than it used to be. systemd became standard thanks to meritocracy (important people in most distros decided to adopt systemd, it was not a "political power play").

It is complex, and there are bugs like any other kind of software[1], however like any other software it is improving.

[1]: For example, I used to hit multiple concurrency bugs in sysVinit used by Arch Linux. The only way to fix them was to find the correct order that system worked. No more problems of this kind thanks to systemd dependency resolving.

geggam12• 8 years ago

Important people choosing to use instead of letting the community decide is the definition of political and not merit

_ofdw3• 8 years ago

systemd became standard thanks to meritocracy (important people in most distros decided to adopt systemd...)

But that's literally the exact opposite of a meritocratic selection.

Tor32• 8 years ago

I need to run /usr/bin/expect from one of the init.d scripts. That breaks with systemd. Moving that box to Devuan (no systemd) fixed the issue. The alternative was to rebuild that particular application without systemd. So far systemd hasn't brought me anything particularly useful. I've never had any issues with getting things working (pre-systemd), and one of my pre-systemd laptops boots from power off to fully graphical in five seconds, so I don't buy the argument I hear from some that systemd is necessary for reducing boot-up time.

welterde• 8 years ago

For example, I used to hit multiple concurrency bugs in sysVinit used by Arch Linux

Arch didn't really use SysVinit before systemd though, but their own BSD-like rc system, which I rather enjoyed actually.. And I got hit with concurrency issues after the switch to systemd, because seemingly the dependencies for disks and file systems aren't setup correctly by the Arch scripts requiring me to add a few fake units to fix up the dependencies (otherwise the system would just fail to boot at all most of the time).

StreamBright6• 8 years ago

You must be joking. What meritocracy? The guy who wrote systemd had already a major failed projects under his belt. PulseAudio rings a bell? Every reasonable person understand that separation of concerns is a good thing. Systemd does the exact opposite.

Few articles to be familiar with regarding systemd:

https://www.dedoimedo.com/computers/software-development-can...

"The same can be said of the init systems in Linux, like systemd. In a nutshell, the system should start quickly and get into a working session. We had this in 2010 or so, with boot times down to mere 10 seconds using init. No flaws, no bugs. Even in the commercial sphere, working with init, I do not recall any major problems.

Then, suddenly, we have this new binary diarrhea with a hundred million modules, and for the past five years, this unstable, half-baked, undebuggable nonsense is the backbone of most Linux distros. The invasive and pervasive nature of the systemd framework has also affected the stability of the user space, the very thing it should never have touched, and pretty much all problems with the quality of the Linux desktop nicely coincide with the introduction of systemd. The development continues, of course, and for no good reason than trying to reach the level of stability, maturity and functionality that we had half a decade ago. Someone landed themselves a lot of monthly pay checks by writing complex code to solve a problem that did not exist."

https://ewontfix.com/14/

"None of the things systemd "does right" are at all revolutionary. They've been done many times before. DJB's daemontools, runit, and Supervisor, among others, have solved the "legacy init is broken" problem over and over again (though each with some of their own flaws). Their failure to displace legacy sysvinit in major distributions had nothing to do with whether they solved the problem, and everything to do with marketing. Said differently, there's nothing great and revolutionary about systemd. Its popularity is purely the result of an aggressive, dictatorial marketing strategy including elements such as:

Engulfing other "essential" system components like udev and making them difficult or impossible to use without systemd (but see eudev).

Setting up for API lock-in (having the DBus interfaces provided by systemd become a necessary API that user-level programs depend on).

Dictating policy rather than being scoped such that the user, administrator, or systems integrator (distribution) has to provide glue. This eliminates bikesheds and thereby fast-tracks adoption at the expense of flexibility and diversity."

Solaris already had a better replacement for initv so did some linux distros.

I think we need a better alternative that does not behave as a black hole, ntp, dns resolution, logging etc. do not get sucked into it and finally we need a way better implementation that does not have a remove or local priv escalation every other week[1].

https://github.com/systemd/systemd/issues

_ofdw3• 8 years ago

Me too. Ironically, systemd is why I bought a Mac.

It's so hard to find a linux distro that actually works on a laptop but doesn't use systemd, so I eventually just gave up on Linux entirely.

That left me with BSD, Windows, and macOS.

I tried FreeBSD and OpenBSD but performance was atrocious and noticeably worse in almost every way than Debian and win7 on the same hardware. I'm sure BSD makes a good server OS but it's just not mature enough for serious work unless I was willing to keep my laptop plugged 99% of the time. But what's the point of a laptop if the OS performs so poorly it won't even last a 4-hour flight?

I similarly seem to be the last guy on earth who still remembers the bad old days of Microsoft's dominance so I won't pay for windows.

The winner by default is therefore apple.

Tor32• 8 years ago

Devuan works fine on my laptop and doesn't use systemd. It's nearly exactly as Debian otherwise.

pedroaraujo• 8 years ago

You bought a Mac because of systemd? Isn't that some sort of overreaction?

zcid• 8 years ago

Sorry you had such a bad time with OpenBSD. It isn't top of the heap when it comes to performance but there are benefits that balance it out.

On the Linux front, I've been using Void and it has been pretty fantastic. Runit is the default init. It is a more hands-on distro (think Arch 10 years ago), but it's fast, slim, and doesn't have systemd.

snazz• 8 years ago

When you tested OpenBSD, did you enable apmd for power management? This significantly improves my battery life (by about 3 hours).

vetinari4• 8 years ago

It's so hard to find a linux distro that actually works on a laptop but doesn't use systemd

Don't you think that there's a reason for that? That systemd solves the problems that make it possible to react to events and makes laptop-usable distros possible?

Meanwhile, enjoy launchd. Maybe you will find out, that they are conceptually similar.

diffeomorphism4• 8 years ago

So when did you leave Mac due to it using launchd?

delcaran• 8 years ago

Slackware64 14.2 runs fine on my 10yo mediocre (for the time) laptop. Don't know about battery though, mine it's too old to be useful.

arianvanp2• 8 years ago

Interesting choice you have there. Systemd is heavily influenced by launchd, the service manager that makes MacOS tick. They're very similar in design. IPC based, socket-activated, property-based, dependencies, parallel startup, unifying init and service management...

https://en.m.wikipedia.org/wiki/Launchd

_emacsomancer_6• 8 years ago

There are a number of desktop/laptop distros which don't use systemd. Void Linux is one such (it uses runit), and it's very easy to use.

dsign• 8 years ago

I worked with both SysV init and updstart. Upstart was not too bad. SysV init was giant piles of bash-script, always slightly different from service to service and from distro to distro. Bash is a language which two decades after, working full time in Linux, I don't completely grasp. Just a few months back we got a client still stuck on SysV init, we ran this algorithm with him:

https://xkcd.com/2083/

insertcredit14• 8 years ago

If you don't grasp bash after two decades of Linux experience, you should maybe question yourself as to why that is rather than blame bash. Maybe you never properly spent a few days fulltime trying to learn it?

I'd take bash scripts without hesitation over systemd any day of the week. I can debug bash with my eyes closed. Every single time I had to debug systemd, I wanted to kill myself.

tyu10002• 8 years ago

Yes, systemd makes being an application developer on Linux so much easier. You can declaratively control state of your daemons, recover from crashes, add process limits, control startup order correctly and on and on.. Much more readable and usable than bash scripts pulling in random libraries and using endless greps to find out system state.

pdkl953• 8 years ago

Bash is a language which two decades after, working full time in Linux, I don't completely grasp.

Have you taken the time to actually read the read the bash(1)? I've noticed that a lot of people (myself included) don't learn sh/bash (and shell scripting in general) initially out of necessity, not with the intent to actually learn the language. If someone wanted to learn a "normal" programming language like C++, Java, or Rust, the would probably start by reading tutorials or guides that cover the major features and teach the core concepts[1].

With bash, most people appear to start with trying to fix something like a build/install script, often resulting in cargo culting a few lines from stackoverflow, forums, "cool one line tricks"-style blog posts, or similar community resources. These can be very helpful[2], but they are not really a way to actually learn the fundamentals of the language.

For me, bash programming initially was very confusing. After I finally forced myself to take the time to actually read the docs/etc, I realized I was making a few incorrect assumptions[3] about the language. After fixing that and learning a few important tricks[4], bash became a lot easier to understand. Now it's one of my favorite languages (for simple tasks).

[1] e.g. (C) pointers, (Rust) variable ownership/borrowing

[2] http://mywiki.wooledge.org/BashFAQ

[3] IO had a lot of trouble initially trying to figure out how to return values from a function. This was hard because, bash "functions" are not really functions like you would find in most languages. I had assumed that you would return values form functions, which breaks when you try to return anything besides an integer. (bash "functions" like foo() { echo "bar" ; } defines programs that return data by writing to stdout).

[4] Always quote variables. Always use curly brackets when using variables ("Hello,, ${name}", not "Hello, %name"). Using $* is almost always wrong; Use "$@" (with the double quotes) instead, which correctly handles spaces/bad-chars in filenames.

BenjiWiebe• 8 years ago

As a counter point, I personally enjoy using systemd to manage my home servers and PC. And I have written unit files for quite a lot too, and enjoy it.

Surprisingly, it seems as if different people have different tastes/opinions. :)

0xbadcafebee2• 8 years ago

And I wish we could just use it for services! But alas, it comes with a free mandatory proctology exam, by a guy with really big hands, called "pid 1".

What's also kind of funny to me is, it wasn't designed for cloud-based services. We now have to invent whole new systems that look a lot like systemd just to manage distributed decentralized services that run on Linux systems.

Systemd would have been great for everybody if it had been developed by people with different priorities.

AsyncAwait3• 8 years ago

I also enjoy systemd much more than sysvinit, having a uniform service structure vs messy shell scripts really does make a difference.

gsich2• 8 years ago

systemd is very easy and nice to use. Why waste your life writing init scripts.

kadendogthing• 8 years ago

Woah there, careful with that opinion.

ape4• 8 years ago

Top comment from reddit thread: FWIW distros that use -fstack-clash-protection to compile systemd, including recent Fedora and OpenSUSE, aren't vulnerable.

https://www.reddit.com/r/linux/comments/aeac8g/systemd_earns...

detaro• 8 years ago

It says so in the article too.

nailer4• 8 years ago

Also in the article:

To the best of our knowledge, all systemd-based Linux distributions are vulnerable, but SUSE Linux Enterprise 15, openSUSE Leap 15.0, and Fedora 28 and 29 are not exploitable because their user space is compiled with GCC's -fstack-clash-protection.

krylon• 8 years ago

Does that include openSuse Tumbleweed?

userbinator2• 8 years ago

I'm of two minds when it comes to mitigations like this. On the one hand, it helps decrease the number of exploits. On the other hand, it encourages/tolerates the proliferation of low-quality code.

loeg16• 8 years ago

Stack clash protection is a necessary implementation detail of the C language. It's a shame it's even optional. C17 § 6.5.16.1 Simple assignment, Semantics, (3):

If the value being stored in an object is read from another object that overlaps in any way the storage of the first object, then the overlap shall be exact and the two objects shall have qualified or unqualified versions of a compatible type; otherwise, the behavior is undefined.

Also listed under J.2 "Undefined Behavior," with reference to the same section.

The same clause is present in C11 and C99 under the same section.

AdmiralAsshat• 8 years ago

First CVE I've seen to reference a System of a Down song.

(Every subsection starts with an SOAD song quote)

nailer4• 8 years ago

Off topic, but SOAD were really one of the most enduring metal acts of the early 2000s. If you remember them, Needle Drop recently did a classic review of Toxicity - enjoy the nostalgia! https://www.youtube.com/watch?v=-jI1ofec02A

rconti• 8 years ago

I'm not a SOAD fan, but good to see someone at my former employer still has a sense of humor :)

Twirrim2• 8 years ago

I might be reading that article wrong, but it reads like they're critical of the use of alloca? I've never really written C or the like, what is dangerous about alloca?

speps• 8 years ago

Variable size allocation from the stack... That's one dangerous trick.

[1] https://stackoverflow.com/questions/1018853/why-is-the-use-o...

pilif• 8 years ago

It allocates on the stack which is inherently of limited size and allocations grow in the direction of the “juicy” stuff.

As so often with the C library, there is little bounds checking going on either (in fact, the behavior once you overflow the stack is explicitly undefined, so who knows what the hell is going to happen)

If you somehow let the user specify the amount of bytes you’re going to allocate on the stack, then that’s an exploitable issue.

Twirrim2• 8 years ago

Ah, OK. So it is truly horrifying that it's in heavy use in journald, where users inevitably have that sort of power.

segfaultbuserr5• 8 years ago

Yet another proof for the following:

1. It's reasonable to claim that amd64 (x86_64) is more secure than x86. x86_64 has larger address space, thus higher ASLR entropy. The exploit needs 10 minutes to crack ASLR on x86, but 70 minutes on amd64. If some alert systems have been deploy on the server (attacks need to keep crashing systemd-journald in this process), it buys time. In other cases, it makes exploitation infeasible.

2. CFLAGS hardening works, in addition to ASLR, it's the last line of defense for all C programs. As long as there are still C programs running, patching all memory corruption bugs is impossible. Using mitigation techniques and sandbox-based isolation are the only two ways to limit the damage. All hardening flags should be turned on by all distributions, unless there is a special reason. Fedora turned "-fstack-clash-protection" on since Fedora 28 (https://fedoraproject.org/wiki/Changes/HardeningFlags28).

If you are releasing a C program on Linux, please consider the following,

    -D_FORTIFY_SOURCE=2         glibc hardening

    -Wp,-D_GLIBCXX_ASSERTIONS   glibc++ hardening

    -fstack-protector-strong    stack smash protection

    -fstack-clash-protection    stack clash protection

    -fPIE -pie                  better ASLR protection

    -Wl,-z,noexecstack          don't allow code on stack

    -Wl,-z,relro                ELF hardening

    -Wl,-z,now                  ELF hardening

Major Linux distributions, including Fedora, Debian, Arch Linux, openSUSE are already doing it. Similarly, Firefox and Chromium are using many of these flags too. Unfortunately, Debian did not use `-fstack-clash-protection` and got hit by the exploit, because it was only added since GCC 8.

For a more comprehensive review, check

* Recommended compiler and linker flags for GCC:

https://developers.redhat.com/blog/2018/03/21/compiler-and-l...

* Debian Hardening

https://wiki.debian.org/Hardening

devereaux4• 8 years ago

What is the performance overhead for using these flags?

segfaultbuserr5• 8 years ago

It's very hard to find solid numbers, because these flags are introduced and popularized at different times. But I'll try to give you my best summary. Long shory short, these flags are considered essentially and most web browsers and distributions have already enabled them without problems.

Let's see...

    -D_FORTIFY_SOURCE=2
    -Wp,-D_GLIBCXX_ASSERTIONS

These two are considered very cheap. It enables some sanity checks for buffer overflow in glibc and glibc++, respectively. See https://access.redhat.com/blogs/766093/posts/3606481 and

    -fstack-protector-strong

Also known as stack canary. The earliest version is simply called "-fstack-protector", but the coverage was bad (only "protects" <2% functions), there was also "-fstack-protector-full", adding checks to ALL functions, but the performance overhead is unacceptable. The "-strong" variant is an upgraded version, it uses a heuristic when determining if a function needs stack protectors, provides much better code coverage and a tradeoff between security and performance.

It's relatively expensive, but is considered essential to prevent attackers from smashing the stack, and is enabled in most web browser engines.

See https://lwn.net/Articles/584225/

    -fstack-clash-protection    stack clash protection

Introduced in GCC 8.0 after the Stack Clash attack was discovered, see https://securingsoftware.blogspot.com/2017/12/stack-clash-pr...

    -fPIE -pie                  better ASLR protection

PIE is Position Independent-Executable, Address Space Layout Randomization needs it to achieve its full level of protection. It has been around for a long time, but only saw a mass adoption recently, possibly due to higher performance impact on 32-bit x86, but favorable on 64-bit systems.

Red Hat has a performance analysis.

* https://access.redhat.com/blogs/766093/posts/1975803

Arch Linux has also benchmarked its performance impact before deciding to enable it.

* https://github.com/pid1/test-sec-flags/wiki

    -Wl,-z,noexecstack          don't allow code on stack

It just disables the executable stack, no overhead. And normally the stack is NOT executable, unless under some special conditions like linking assembly code, due to bad default settings in GNU toolchains for historical reasons. This explicitly tells the linker: don't allow an executable stack, no matter what.

    -Wl,-z,relro                ELF hardening
    -Wl,-z,now                  ELF hardening

It marks the GOT table as readonly, and force the system to resolve all function references to shared libraries at startup time, instead of runtime. It has some impact on startup time, but mostly negligible.

See https://blog.osiris.cyber.nyu.edu/exploitation%20mitigation%....

wahern5• 8 years ago

FWIW, the stack vulnerabilities here aren't just a C problem. Most languages, including every language relying on LLVM and GCC until the most recent versions, failed to perform stack probing.

I hesitate to call stack probing "hardening". IMO it's better understood as a failure by compilers to emit proper code in the first place, and it's been a glaringly obvious deficiency for years if not decades.

ajross• 8 years ago

These are alloa overflows. In the first one, the code tries to put the entire (attacker-controlled) command line on its stack. Compilers can't detect or prevent that, though with ABI support they may be able to detect it before failure

wbl• 8 years ago

Please point to the line of the spec requiring stack probing.

lmm2• 8 years ago

"Proof" suggests a level of absolute confidence that this example certainly does not give.

The exploit needs 10 minutes to crack ASLR on x86, but 70 minutes on amd64.

Is there any realistic threat model under which the difference between 10 minutes and 70 minutes is the difference between "insecure" and "secure"?

Using mitigation techniques and sandbox-based isolation are the only two ways to limit the damage.

I'm not at all convinced that mitigation techniques represent a real improvement in security, because by definition a mitigation technique is not backed by a solid model. If you're letting an attacker control the modification of memory that your security model assumes isn't modifiable, how confident can you be that ad-hoc mitigations for all the ways you could think of to exploit that cover all the possible ways to exploit that? E.g. I can remember a time when ASLR was touted as a solution to C's endemic security vulnerabilities; now cracking ASLR as part of vulnerability exploitation is routine, as seen here. Mitigations appear to give a security improvement because an app with mitigations is no longer the low-hanging fruit, but I suspect this is a case of "you don't have to outrun the bear": as long as there are C programs without mitigations, attackers will go after those first. That's different from saying that mitigations provide substantial protection.

FakeComments• 8 years ago

The hands-on-keyboard SLA for a lot of on-calls is 30 minutes.

So in an “attack was detected, break all the glass” scenario, the difference between 10 and 70 minutes is sufficient to allow human operators to render the attack moot by offlining its target, while the attackers are still trying to break through API servers.

At both big corps I’ve been at, the incident response plan for an exfiltration attack on customer data was invalidate DB creds and take the system down ourselves.

Better to be out of service than lose custody of customer data.

dTal• 8 years ago

Is there any realistic threat model under which the difference between 10 minutes and 70 minutes is the difference between "insecure" and "secure"?

How about an intrusion detection system that flags up a human response? 10 minutes is hardly any time at all to respond, an hour gives you a chance to roll out of bed.

okket• 8 years ago

A server suddenly spiking full load for over an hour should raise alarms. It shows up even in the dumbest of 5 minute averaging charting tools.

A few minutes of high load can easily get overlooked.

segfaultbuserr5• 8 years ago

Is there any realistic threat model under which the difference between 10 minutes and 70 minutes is the difference between "insecure" and "secure"?

Time is given here just for an example. To crack systemd, it only takes 70 minutes, but in general, bruteforcing ASLR on 64-bit systems can take as few as 1.3 hours but as many as 34.1 hours, depending on the nature of bug. On the other hand, the ~20-bit of entropy on 32-bit systems is trivial to crack in 10 minutes for nearly all cases, and does not provide an adequate security margin.

Oon a 64-bit system there is ~32-40 bit of ASLR entropy available for a PIE program. It forces an attacker to brute-force it. Unlike other protections, no matter how is the system cleverly analyzed beforehand, it taxes the exploit by forcing it to solve a computational puzzle. This fact alone, is enough to stop many "Morris Worm"-type remote exploitations (they have suddenly became a serious consideration, given the future of IoT), since an exploit takes months or years to crack a single machine.

If it's not enough (it is not, I acknowledge ASLR by itself cannot be enough), an intrusion detection system should be used, and it already has used by many. For example, PaX offers an optional, simple yet effective anti-bruteforce protection: if the kernel discovers a crash, the `fork()` attempt of the parent process is blocked for 30 seconds. It takes years before an attacker is able to overcome the randomization (so the attacker is likely to try something else). In addition, it also writes a critical-level message to the kernel logbuffer, the sysadmin can be notified, and possibly uncover the 0day exploit the attacker has used. I'd call it a realistic threat model.

Finally, information leaks is a great concern here. Kernels and programs are leaking memory address like a sieve, and effectively making ASLR useless. Linux kernel is already actively plugging these holes (but with limited effectiveness, HardenedBSD should be the future case-study), so should other programs.

e.g. I can remember a time when ASLR was touted as a solution to C's endemic security vulnerabilities; now cracking ASLR as part of vulnerability exploitation is routine, as seen here.

You can make the same comment on NX bit, or W^X/PaX, or BSD jail, or SMAP/SMEP (in recent Intel CPUs), or AppArmor, or SELinux, or seccomp(), or OpenBSD's pledge(), or Control Flow Integrity, or process-based sandboxing in web browsers, or virtual machine-based isolation.

Better defense leads to better attacks, and it in turns leads to better defense. By playing the game, it may not be possible to win, but by not playing it, losing the game is guaranteed. In this case, systemd is exploitable despite ASLR, due to a relatively new exploit technique called "Stack Clash", and for this matter, GCC has already updated its -fstack-check to the new -fstack-clast-protection long before the systemd exploit was discovered. If this mitigation has been used (like, by Fedora and openSUSE), it causes simply a crash, and is not exploitable. At least before the attacker finds another way round.

Early kernels and web browsers have no memory and exploit protections whatsoever: a single wrong pointer dereference or buffer overflow is enough to completely takeover the system. Nowadays, an attack needs to overcome at least NX, ASLR, sandboxing, and compiler-level mitigation, and we still see exploits. So the conclusion is all mitigations are completely useless? If it's your opinion, I'm fine to agree to your disagreement, many sensitive C programs need to be written in a memory-safe language anyway. But as I see it, as long as there are still C programs running with undiscovered vulnerabilities, and as long as attackers have to add more and more up-to-date workarounds and cracking techniques (ROP, anyone? but now the most sophisticated attackers are moving to DATA-ONLY attacks) to their exploit checklist, then we are not losing the race by increasing the cost of attacks.

On the other hand, if an attacker don't have to use an up-to-date cracking techniques, then we have serious problems. For example, broken and incomplete mitigation is often seen in the real word, and it's the real trouble. Recently, it has been discovered that the ASLR implementation in the MinGW toolchain is broken, allowing attackers to exploit VLC using shellcode tricks from the 2000s (https://insights.sei.cmu.edu/cert/2018/08/when-aslr-is-not-r...). And we still see broken NX bit protection and the total absence of any ASLR, or -fstack-protector in ALL home routers (https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-...).

The principle of Defense-in-Depth is that, if the enemies are powerful enough, it's inevitable all protections will be overcame. Like the Swiss Cheese Model (https://en.wikipedia.org/wiki/Swiss_cheese_model), a cliche in accident analysis, eventually there will be something that managed to find a hole in every layer of defense and pass though. What we can do, is to do our best at each layer of defense to prevent the preventable incidents, and adding more layers when the technology permits us.

My final words are: at least, do something. ASLR is already implemented as a prototype, analyzed, and exploited by clever hackers back in 2002 (http://phrack.org/issues/59/9.html), but only seen major adoptions ten years later. It would be a surprise if ASLR-breaking techniques has not improved given the inaction of most vendors.

"Proof" suggests a level of absolute confidence that this example certainly does not give.

I agree. I should've use "given more empirical evidences" instead of "given a proof".

For real security, I believe memory-safe programming (e.g. Rust), and formal verification (e.g seL4) are the way forward, although they still have a long way to go.

vectorEQ2• 8 years ago

you can patch binaries to fix memory corruption issues :D compiler flags won't help on already compiled softwares, and if they are yet to be compiled, the sources could be improved... that being said i'm not against these compiler things, just don't lean on those to fix your broken code... which is what a lot of developers seem to imply when they say this is the way to fix things.

segfaultbuserr5• 8 years ago

Sure, you need both.

I said,

CFLAGS hardening works, in addition to ASLR, it's the last line of defense for all C programs. [...] Using mitigation techniques and sandbox-based isolation are the only two ways to limit the damage.

Mitigations are here to limit the damage, not to eliminate vulnerabilities and exploits.

Looking for bugs and improving the code for security for as hard as you can, and in case you missed one (you certainly will), CFLAGS and ASLR is your last line of defense, and you can only hope for the best that it is able to buy you some time to patch it, before a better exploit appears...

fao_3• 8 years ago

Hey, you will want to add:

  -fcf-protection=full       ROP protection

to that list :)

(see: https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.h...)

loeg16• 8 years ago

I would add: alloca() should be considered harmful and warned out of existence, like gets().

If your malloc() implementation is slow, fix that! tcmalloc and jemalloc have been around for a long time.

dane-pgp3• 8 years ago

I'm reminded that the custom memory allocation system in OpenSSL was cited as being potentially implicated in the Heartbleed bug:

https://www.darkreading.com/vulnerabilities---threats/did-a-...

or it at least made it harder for the code to be analysed by automated tools:

https://dwheeler.com/essays/heartbleed.html#basic-fuzzers

lousken5• 8 years ago

Was systemd ever properly audited? That's exactly why i use devuan as my home server.

tinus_hn4• 8 years ago

Was init?

insertcredit14• 8 years ago

The complexity of Sysvinit is orders of magnitude less than that of systemd.

lousken5• 8 years ago

No, but it's far less complex than systemd to the point where you can audit the code yourself and it's battle tested over the years. Also because it's so simple it was shown to us at the university so we've got essential understanding of how it works and I think they're still explaining it instead of systemd.

TheDong• 8 years ago

Did you pay for an audit of sysvinit and every bash rc script it runs?

I can't think of a single init system which has been audited.

lousken5• 8 years ago

No I didn't but I can read bash so I can audit that myself and in fact over the years I did read most of those scripts. Also it's just a few lines of code compared to systemd so even one person can do it.

josteink5• 8 years ago

As if Devian has had more security reviews than systemd?

insertcredit14• 8 years ago

Devuan is a Linux distribution that does not ship systemd by default.

You are comparing apples and oranges.

vesinisa• 8 years ago

Despite being a security critical component, systemd doesn't even seem to have a proper security announcement release process. For example, there was a remote code execution vuln discovered in their DHCP client in October (CVE-2018-15688).[1] The issue was fixed with a GitHub PR that failed to mention that the changes fix a remote exec vulnerability: https://github.com/systemd/systemd/pull/10518

They also have a rather informal release process. Their "release notes" are just a very long NEWS file[2] in the git repo, with notes of trivial and critical changes mishmashed together. And for some reason, to this date there is not a mention of the DHCP remote exec vuln fixed in the latest release.

I must say I don't feel too good about this project's attitude towards security. Compare this to e.g. Apache.

[1] https://www.theregister.co.uk/2018/10/26/systemd_dhcpv6_rce/

[2] https://github.com/systemd/systemd/blob/master/NEWS

dalai• 8 years ago

That was not the first time either:

https://github.com/systemd/systemd/issues/5144

lima2• 8 years ago

systemd is a low-level building piece for distributions - the distros are doing end-user changelogs and security notices. The target audience for their NEWS file are upstream maintainers, not users.

dralley• 8 years ago

While I agree that it isn't ideal -- it should be pointed out that neither does the kernel itself.

jononor• 8 years ago

Are there static analysis tools that catch such problems? User controlled buffer length for alloca.

sus_007• 8 years ago

If you're curious to know further critics regarding Systemd, then without-systemd[1] has got you covered.

[1] http://without-systemd.org/wiki/index.php/Main_Page

blablabla123• 8 years ago

Yeah I know that one. It puzzles me how systemd has such a broad support among distributions and end users. It just redoes ages of system management in such new ways that they don't exactly fit the picture.

We all know that some stuff of Linux sucks but this can't seriously be the solution. Solving things the windows ways. ;)

yarrel3• 8 years ago

SystemD doesn't have broad support among end users. It has weary resignation and a few people who don't know how grep works.

dabockster2• 8 years ago

I knew it was a bad exploit when I saw stpcpy() being used in the code. Always use the “n” versions (eg stpncpy()) and measure your sizes!

kevin_thibedeau3• 8 years ago

stpncpy() is still brain dead for copying null-terminated strings. Regardless of your viewpoint on truncating strings, the zero-pad behavior is wasteful and rarely necessary.

dabockster2• 8 years ago

My point stands. C/C++ aren’t memory safe. You can’t just copy stuff around in memory and expect the compiler to fix it for you when the sizes don’t match. This isn’t Python or Node.

I’m seriously curious as to why the non-n versions are still allowed to compile. The dangers seem way too real.

newnewpdro5• 8 years ago

Yet the vulnerability has absolutely nothing to do with stpcpy() being used.

The problem is alloca() is used to allocate the space stpcpy() is writing into. Using the 'n' variant here wouldn't have made the slightest difference.

tom_2• 8 years ago

The string.h `n' versions aren't for creating C-style strings, but rather for manipulating 0-padded fixed-size buffers. stpncpy is no exception: the destination is padded if the source is smaller (of course, unnecessary for C-style strings), and the destination is not 0-terminated if the source is too large (not a great idea if you're trying to create a C-style string).

Quite why the stdio.h `n' versions do something different, I couldn't say. They should probably have chosen a different letter, as this stuff has been enough of a pitfall for long enough without adding yet another one into the mix. (One option: following the example of BSD-style `strlcpy', as popularized by Ulrich Drepper, `l'. Too late now, of course.)

kevin_thibedeau3• 8 years ago

Is Coverity being run against systemd? Would it not have found these issues?

uniformlyrandom• 8 years ago

Usefulness of static code analysis beyond linting is greatly overstated (by people selling static code analysis tools).

pjmlp4• 8 years ago

As proven by a large majority of C developers ignoring lint since 1979.

kevin_thibedeau3• 8 years ago

Coverity isn't useless. It finds these kinds of buffer overflow errors easily. It's shameful that a prominent keystone FOSS project is using such outdated coding practices in the first place. Not using the free tooling available for such projects is doubly so.

zzzcpan3• 8 years ago

I suppose prlimit'ing stack size for systemd-journald could work against this exploit too, since clash protection works, but without recompiling anything.

pdkl953• 8 years ago

If we send a large "native" message to /run/systemd/journal/socket ... the maximum size of a "native" entry is 768MB

Why does journal allow such large messages over a socket? That alone might be a denial-of-service attack; are real messages delayed/blocked if someone sends spawns a bunch of processes that send 768MB of junk to that socket?

    commit c4aa09b06f835c91cea9e021df4c3605cff2318d
    Date:   Mon Apr 8 20:32:03 2013 +0200
    ...
    -#define ENTRY_SIZE_MAX (1024*1024*64)
    -#define DATA_SIZE_MAX (1024*1024*64)
    ...
    +#define ENTRY_SIZE_MAX (1024*1024*768)
    +#define DATA_SIZE_MAX (1024*1024*768)

WTF? Why would you need to increase the max size so much? What are you intending to send over that socket?! Oh. From the commit[1], the missing lines at the 2nd "...":

    +/* Make sure not to make this smaller than the maximum coredump
    + * size. See COREDUMP_MAX in coredump.c */

Why would you send coredumps over a socket? Just write them to a file and send the file's path to journald. Increasing the max message size 1200% just to avoid writing a core file is crazy.

[1] https://github.com/systemd/systemd/commit/c4aa09b06f835c91ce...

xena• 8 years ago

Sockets are files internally to Linux.

int0x803• 8 years ago

Another big question is why does it use alloca at all. Considering that it is well known in the C world to be problematic and discouraged. For this very reason.

- Are you performance-constrained? NO.

- Is calling malloc/free such a big deal, instead of alloca? It is not.

Yes. That neat join funcion will need to get an extra parameter and free the returned pointer when it's done with it. This is C. If you want neat convenient string joining functions use a different language.

newnewpdro5• 8 years ago

- Are you performance-constrained? NO.

A significant portion of issues filed against journald are performance related.

It's undesirable to have a bunch of mallocs and frees in the hot path of logging. It's not inappropriate to use the stack where possible, obviously in this case user-controlled input was being trusted where it shouldn't have.

There have been many problems of this sort in journald, where the nature of the user-controlled input has the ability to bring journald to its knees in a global manner.

Prior to the process metadata caching, you could cause journald to go absolutely nuts querying the sending processes metadata from /proc by sending it messages full of newlines. Every newline-separated field is treated as a separate message with its own metadata to be acquired. The routines for fetching all that stuff from /proc granularly allocated and freed the data via libc as well, it was very painful.

Things are better now, but you still can't log particularly high rates through journald compared to a simple O_APPEND style logger like syslogd. Programs synchronously logging debug messages quickly become slowed down by journald pinning a CPU.

You can still cause a world of hurt by spamming journald with tiny emergency messages, each of which forces a sync of the journal. But a user can also run `while true; do sync; done`

groestl• 8 years ago

Playing the devil's advocate here: not every box has a writeable filesystem.

geofft6• 8 years ago

I think this is the right answer - more specifically, a program may not have write access to the filesystem (e.g., with the systemd "ProtectSystem" option). Linux lets you spawn a process to handle a core dump, but I believe the process runs as if it were a child process of the crashing one, i.e., in the same namespace and with the same filesystem permissions.

pdkl953• 8 years ago

Or the only writable filesystem could be a tiny tmpfs/ramdisk. In both situations, do you even want core dumps?

StreamBright6• 8 years ago

The do not core dump.

loeg16• 8 years ago

You could imagine kernel.core_pattern pointing at an NFS mount, or a psuedo-filesystem that otherwise redirected to the network (could even be a small FUSE FS, allowing for userspace handling). Of course, neither of these suggestions necessarily gives control back to systemd to then relocate or process the file. But you couldn't do that on a RO system anyway.

userbinator2• 8 years ago

As Linus might say, "this is complete idiocy".

Even if you need to write a lot of data, the correct way is to write it in blocks using a fixed-size buffer, not try to stuff the whole thing in at once...

Maybe it's not possible to completely eliminate all dynamic allocation, but striving to make your code O(1) space (and time) should be a relatively important goal.

Someone• 8 years ago

The choice may be incorrect, but the alternatives aren’t all around optimal, either.

A logging system must write each message atomically. That can be done when “writing in blocks using a fixed-size” buffer, but it complicates code, and, I guess, would introduce additional latency (something you really do not want in a logging system) when processes race for using the logging system.

Quekid52• 8 years ago

Do you have a close-to-perfect implementation, perchance?

Any logging implementation I have ever seen is full of tradeoffs along all sorts of axes. At some point something has to give.

Examples: Your log cannot accept more messages (maybe it's a local disk), what do you do? Do you store it in memory? Do you throw it away and record that you threw messages away? What happens if the machine dies before you can record the failures? Are there some log messages that are important enough to actually halt the application? etc. etc.

EDIT: ... and let's not even get into remote logging.

It's actually a really complicated problem and not enough people appreciate that.

StreamBright6• 8 years ago

Because systemd tries to hijack as much functionality it can.

WalterGR• 8 years ago

This is demonstrably false.

avar• 8 years ago

I'd imagine that the use-case for this was e.g. aggregating core dumps via some sytsemd/journald-powered centralized logging from a fleet of machines so they could be collected & analyzed.

If you dump core locally and log the path you'll need other side-channel to do the aggregation.

rleigh8• 8 years ago

I would never expect that core dumps to belong in a system logger of any description. A stack trace from the dump, maybe. But the actual core itself, could be tens of gigabytes. A constraint upon the maximum message size to a few kilobytes would be no bad thing, perhaps with a continuation mechanism for longer messages.

a-dub• 8 years ago

I believe it's so they can manage disk usage by core dumps (and disable them in low disk conditions).

It's certainly weird, but they're only exploiting this to slow things down just a little bit.

The big problem is the unchecked length of the incoming environment (args) string...

Asooka• 8 years ago

Additionally, the one time I actually needed coredumps, they didn't fit in 768MB and so I had to turn off systemd's coredump interceptor. It's probably useful in certain scenarios, but I really don't see why you would enable coredumpctl on a desktop system. Or why the limit would be hardcoded. Or why you wouldn't intelligently try to write the coredump to disk if it's too big to fit in the log.

pas3• 8 years ago

if it's more than ~5M I don't want it on my desktop. usually it's not set up anyway to warrant sending it to developers for debugging. (missing symbols, unclean environment, etc) and even if it's less than ~5M, who will send it to where? coredumps are completely useless to do automatically. if the developers expect to get them, use a guardian process or some other error reporting framework.

gmueckl4• 8 years ago

Systemd's insistence to gobble up core dumps is one of my favorite misfeatures of that thing. I lost many an interesting (large) dump because they wouldn't be logged in the journal and not be written to file as expected. Luckily this can be disabled (until the next system update resets the syscfg variable again). I don't even get what problem this "feature" is supposed to solve.

vidoc• 8 years ago

and at some point it was even comedy gold when the system would compress them with ... xz! lol

egberts1• 8 years ago

I still use ISC DHCP client due to enterprise DHCP using some esoteric DHCP Options that systemd cannot do to this day.

kazinator3• 8 years ago

https://wiki.sei.cmu.edu/confluence/display/c/MEM05-C.+Avoid...

This compliant solution replaces the VLA with a call to malloc(). If malloc() fails, the return value can be checked to prevent the program from terminating abnormally.

Wishful thinking. On overcommit-enabled VM systems (pretty much every GNU/Linux desktop and server by default), malloc will cheerfully return a valid-looking pointer to virtual memory even if the system is out of memory. Your process will get a fatal signal when later it tries to use the memory. It will not be prevented from terminating abnormally.

Any page of the memory could blow up. Maybe the first three pages get a frame just fine, but when the process touches the fourth, it faults.

The reason to use malloc instead of the stack is that it goes awry only when the system is out of memory, not when the stack is out of room.

geofft6• 8 years ago

But the only failure case there is a DoS. You cannot get memory corruption from overcommit the way you can from a stack clash, and therefore you cannot get arbitrary code execution. That seems like a huge reason to prefer overcommit.

kazinator3• 8 years ago

Stack clashes are protected with guard pages. Guard pages can be skipped, but not by code like strjoina which fills in all of the bytes.

https://www.qualys.com/2017/06/19/stack-clash/stack-clash.tx...

The reporters do claim to have a root exploit that they will publish later, which will be interesting (if it still applies on systems with robust guard pages).

The strings are copied into the alloca area from the lower address to the higher, so initially, the stpcpy calls might be corrupting memory belonging to an adjacent mapping and not to the stack. Eventually the loop has to cross back into the stack, and it cannot do so without writing into a guard page.

Situations where that is still exploitable can be contrived. For instance, the program sets up a SIGSEGV handler to execute on an alternate stack using sigaltstack. When the stack guard page is hit, that handler executes successfully, the program continues somehow (e.g. by a recovering longjmp that rewinds the stack) and then falls victim to the corruption.

One thing we can do is after calling alloca, walk over the memory in reverse order (higher address to lower) in strides of 4096 bytes, and touch a byte at every increment. This way we hit the guard page (on any system that has a page size of at least 4096).

loeg16• 8 years ago

Systems that care about reliability and avoiding random overcommit crashes disable overcommit. It's as simple as that.

loeg16• 8 years ago

I should add, the thorough guidelines quoted are for writing secure and robust programs, and imply throughout that overcommit is disabled (which it must be, to implement programs robustly).

_emacsomancer_6• 8 years ago

systemd is interesting as an innovative init/daemon-manager(+), but I remain convinced it's not ideal that it is de facto Linux default init. Surely the default init should be something more manageable (i.e. with fewer attack surfaces) like runit or OpenRC (in combination with something, perhaps runit) or s6 etc.

chousuke• 8 years ago

This attack doesn't touch the init system's attack surface though. It breaks journald, which is a separate program that you don't even have to run (syslog daemons still work)

Calling this a bug in the init system is like assigning fault for bugs in eg. rsyslog to sysvinit

insertcredit14• 8 years ago

This is disingenuous, systemd-journald is the default in every systemd-using distribution I am aware of. The philosophy of systemd is all about tight coupling and forcing its singular vision on end users. When that vision falls apart you can not claim it is not really a systemd problem because in theory you could have gone out of your way and done something that is not encouraged.

_emacsomancer_6• 8 years ago

But you know that my post is a criticism of the systemd ecosystem, or, more specifically, its status as the de facto. All my systems that run systemd run journald; all of my systems that run journald run systemd. Because those are the choices the distro devs made. My systems which don't run systemd are immune to these vulnerabilities.

gmueckl4• 8 years ago

No, you cannot run systemd without journald. Journald can forward messages to another syslog implementation. Its launch is even hardcoded into systemd very early in the boot process IIRC. The intent is to capture early log messages in memory inside journald before a writable /var is available.

zanny• 8 years ago

You can go start your own systemd free distribution.

For everyone else, there is a reason they centralized on it, and its not because Lennart was stalking their mailing lists threatening to send them expired cheese. Systemd is not perfect, but it is infinitely better than a sludge of shell scripts.

_emacsomancer_6• 8 years ago

There already are plenty of systemd-free distributions. Not because the developers hated systemd, but because they decided using a baroque init+daemon-manager+logger+.... wasn't the best idea.

For everyone else, there is a reason they centralized on it, and its not because Lennart was stalking their mailing lists threatening to send them expired cheese. Systemd is not perfect, but it is infinitely better than a sludge of shell scripts.

This is such a disingenuous argument. Don't like Ford? What, you want the horse-and-carriage back?

I'm not arguing for sysv init. Nothing in what I've said references sysv init, and - if my choices were (a) sysv init, and, (b) systemd, I would indeed choose (b). But that isn't the full range of choices.

There are various non-sludge-of-shell-script choices which aren't systemd. Including OpenRC, s6, runit, Shepherd. I haven't used the first two extensively, but I have the latter two, and both were better experiences than systemd: they are faster, they are more comprehensible, and they are less error-prone.

On the other hand, my systemd-running home desktop - every time I want to reboot, I end up REISUB'ing it because I don't feel like waiting 2-5 minutes for systemd to release it. I don't have that issue on any of my other, non-systemd-powered machines. They all shut down/reboot cleanly and quickly.

loeg16• 8 years ago

I think it would be great to run systemd as pid 2 with a bare-bones pid 1 that only took on the responsibility of (1) spawning a service manager as pid 2, and (2) killing reaping zombies. This is pretty much what BSD's init(8) does today[0], except with /etc/rc as pid 2 instead of systemd.

(I'm not advocating for /etc/rc — it sucks. I much prefer systemd-style dependencies, service management, etc. But bloating the code size and responsibility of pid 1 is a common systemd complaint that would be trivial to fix.)

[0]: Well, it does some other crap too that could / should probably be removed, like having a notion of run level (multiuser, single user) and spawning getty(8)s. But mostly it's a tiny barebones program that spawns pid 2 and reaps zombies.

_emacsomancer_6• 8 years ago

I think it would be great if such things were options, yes. Despite the common argument that systemd is actually modular, I haven't seen a lot of modular use of its pieces. In practice, use of systemd (and, again, I'm complaining more about distro devs than systemd devs) has seem to make things more inflexible (and brittle). E.g. Gnome Shell ended up with a practical dependency on systemd, though this has been successfully worked around. Snaps ("Snaps are universal Linux packages") are really 'universal systemd packages' (and in fact only 'universal Ubuntu packages' if you want sandboxing). But hopefully at some point it will be possible to more easily use the good bits of systemd without having to go 'whole hog' (so to speak).

eikenberry• 8 years ago

I don't see any systems with security releases ready. Did they not notify the effected systems before making it public? I thought that was standard procedure these days.

kasabali3• 8 years ago

It's in the linked page:

2018-11-26: Advisory sent to Red Hat Product Security (as recommended by https://github.com/systemd/systemd/blob/master/docs/CONTRIBU...).

2018-12-26: Advisory and patches sent to linux-distros@...nwall.

2019-01-09: Coordinated Release Date (6:00 PM UTC).

upofadown• 8 years ago

On a Debian stable (9.5), our proof of concept wins this race and gains eip control after a dozen tries (systemd automatically restarts journald after each crash):

Seems like a good example of why automatically restarting things that crash is a bad idea.

loeg16• 8 years ago

As with anything, there are tradeoffs.

A dozen is too short to really make a difference, but one thing that can be done at the service management layer without abandoning restart entirely is a delayed restart, or exponential backoff.

You could also imagine a per-service option for auto restart. Paranoid organizations with plenty of on-call engineers could disable auto-restart, if they were convinced the engineers wouldn't just rig up their own auto-restart to avoid the call.

z3t4• 8 years ago

How can you check if you systemd is patched ? This sounds very serious.

throw2016• 8 years ago

There is a pattern of designing for the most niche use cases and imposing complexity on everyone by default. Shouldn't it be the other way round? Letting those with advanced needs accept the complexity? Presumably they have the know how.

There are multiple examples of this including the binary journal for those with extreme auditing needs, optimizing for laptop wifi networks when Linux is predominantly used in servers, the ironically named 'predictable network names' that are anything but predictable. And these issues being hand-waved away because of some fringe use case with the additional overhead nonchalantly imposed on all users.

codedokode4• 8 years ago

I think that putting a hard limit on alloca allocation size, somewhere around 1-10 Kb, could help prevent this type of exploits. Also, it is possible to write a function that would choose between alloca() and malloc()/free() depending on the size.

posix_me_less• 8 years ago

It's been two weeks since the GNU/Linux distributors were notified of this, and still no fixes are available in Redhat/Centos/Debian.

Any ideas about how to mitigate this until official fixes are available? Would it help to block autorestart of journald? Any idea about how to that?

System Down: A systemd-journald exploit

Related Stories