The D in Systemd stands for 'Dammmmit!' A nasty DHCPv6 packet can pwn a vulnerable Linux box A security bug in Systemd can be exploited over the network to, at best, potentially crash a vulnerable Linux machine, or, at worst, execute malicious code on the box. The flaw therefore puts Systemd-powered Linux computers – specifically those using systemd-networkd – at risk of remote hijacking: maliciously crafted DHCPv6 …
https://pipewire.org/
Oh my sweet olfactory system it really exists. WE DON'T NEED ANOTHER AUDIO SUBSYSTEM THERE ARE LIKE 5 ALREADY... sndio, alsa, pulse, oss, jack...
"It aims to support the usecases currently handled by both PulseAudio and Jack and at the same time provide same level of powerful handling of Video input and output."
Ah, Gunther, remove me from this mortal coil immediately. And after that, lunch.
This post has been deleted by its author
Stringing up the Potty pour encourager les autres seems quite reasonable to me, but we need to realise that there will always be a sufficient supply of fucktards whose egos massively outstrip their abilities, and who are willing to implement the most deranged ideas, like hijacking the init system to execute a massive land grab, under the guise of "modernising it".
New lamps for old.
That so many supposedly technical people have gone along with this is very disappointing, but it's entirely in line with our being doomed by our own stupidity, so nothing new.
That it punches thru NAT routers enabling all your little goodies behind them as directly accessible.
MS even supplies tunneling (Ivp4 to Ivp6) so if using Linux in a VM on a MS system you may still have it anyway.
NAT was always recommended to be used in hardening your system, I prefer to keep all my idIoT devices behind one.
As they are just Idiot devices.
In future I will need a NAT that acts as a DNS and offers some sort of solution to keeping Ivp4.
While I've not played with it much, it shouldn't be too difficult to set up the router/gateway as v6 but everything behind it on v4. Only do V4 DHCP etc, firewall blocks any v6 on the wrong side of the fence.
At least till some potty thing comes along and breaks security yet again.
You can use NAT with IPv6.
You can, but why would you want to.
NAT is schtick for connecting a whole LAN to a WAN using a single IPv4 address (useful with IPv4 because most ISPs don't give you a /24 when you sign up). If you have a native IPv6 address you'll have something like 2^64 addresses, so machines on your LAN can have an actual WAN-visible address of their own without needing a trick like NAT.
Using NAT with IPv6 is just missing the point.
"so machines on your LAN can have an actual WAN-visible address of their own without needing a trick like NAT."
Avoiding that configuration is exactly the use case for using NAT with IPv6. As others have pointed out, you can accomplish the same thing with IPv6 router configuration, but NAT is easier in terms of configuration and maintenance. Given that, and assuming that you don't want to be able to have arbitrary machines open ports that are visible to the internet, then why not use NAT?
Also, if your goal is to make people more likely to move to IPv6, pointing out IPv4 methods that will work with IPv6 (even if you don't consider them optimal) seems like a really, really good idea. It eases the transition.
'tis you who misses the point.
I don't want every machine on my lan having it's own world-visible address. It serves no benefit to me, means I have to spend a lot more time faffing around with firewalls etc (rather than having just one decent gateway), can never be fully sure a machine is fully secured, have no protection against friends/family coming in other than to deny them access to the network.
With NAT I need to be sure my borders are secure, but I need not worry about anything inside my borders. The holes through my borders are ones I make knowingly. Ones made by bugs are much harder to exploit with NAT than with a leaky firewall, of which I might find winth v6 that I have a dozen to fix in a small amount of time (and of course since the firewall is the machine's only protection, I can't as easily isolate it until I have something better installed as I can with NAT).
I still run OK firewalls on each machine as I do have guests on my network, but I don't need to work nearly as hard at protecting my machines from them as I do at protecting my machines from outsiders. And with IPV6 I have to do that work on every machine.
NAT makes my life a lot easier, and that's the point of keeping it around. I don't have a use for machines being able to bypass my gateway, and I don't want them to. At some stage I expect to go IPV6 at the gateway, but I will remain on NAT/v4 inside.
My NAT router statefully firewalls incoming IPv6 by default, which I consider equivalently secure. NAT adds security mostly by accident, because it de-facto adds a firewall that blocks incoming packets. It's not the address translation itself that makes things more secure, it's the inability to route in from the outside.
The bug will come as another argument against Systemd as the Linux management tool continues to fight for the hearts and minds of admins and developers alike.
Less against systemd (which should get attacked on the design & implementation level) or against IPv6 than against the use of buffer-overflowable languages in 2018 in code that processes input from the Internet (it's not the middle ages anymore) or at least very hard linting of the same.
But in the end, what did it was a violation of the Don't Repeat Yourself principle and lack of sufficently high-level datastructures. Pointer into buffer, and the remaining buffer length are two discrete variables that need to be updated simultaneously to keep the invariant and this happens in several places. This is just a catastrophe waiting to happen. You forget to update it once, you are out! Use structs and functions updating the structs correctly.
And use assertions in the code, this stuff all seems disturbingly assertion-free.
Excellent explanation by Felix Wilhelm:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1795921
The function receives a pointer to the option buffer buf, it's remaining size buflen and the IA to be added to the buffer. While the check at (A) tries to ensure that the buffer has enough space left to store the IA option, it does not take the additional 4 bytes from the DHCP6Option header into account (B). Due to this the memcpy at (C) can go out-of-bound and *buflen can underflow [i.e. you suddenly have a gazillion byte buffer, Ed.] in (D) giving an attacker a very powerful and largely controlled OOB heap write starting at (E).
why don't we stop writing code in languages that make it easy to screw up so easily like this?
There are plenty about nowadays, I'd rather my DHCP client be a little bit slower at processing packets if I had more confidence it would not process then incorrectly and execute code hidden in said packets...
The circus that is called "Linux" have forced me to Devuan and the likes however the circus is getting worse and worse by the day, thus I have switched to the BSD world, I will learn that rather than sit back and watch this unfold As many of us have been saying, the sudden switch to SystemD was rather quick, perhaps you guys need to go investigate why it really happened, don't assume you know, go dig and you will find the answers, it's rather scary, thus I bid the Linux world a farewell after 10 years of support, I will watch the grass dry out from the other side of the fence, It was destined to fail by means of infiltration and screw it up motive(s) on those we do not mention here.
Hello:
As many of us have been saying, the sudden switch to SystemD was rather quick, perhaps you guys need to go investigate why it really happened, don't assume you know, go dig and you will find the answers, it's rather scary ...
Indeed, it was rather quick and is very scary.
But there's really no need to dig much, just reason it out.
It's like a follow the money situation of sorts.
I'll try to sum it up in three short questions:
Q1: Hasn't the Linux philosophy (programs that do one thing and do it well) been a success?
A1: Indeed, in spite of the many init systems out there, it has been a success in stability and OS management. And it can easily be tested and debugged, which is an essential requirement.
Q2: So what would Linux need to have the practical equivalent of the registry in Windows for?
A2: So that whatever the registry does in/to Windows can also be done in/to Linux.
Q3: I see. And just who would want that to happen? Makes no sense, it is a huge step backwards.
A3: ....
Cheers,
O.
OK, so I was able to check through the link you provided, which says "up to and including 239", but I had just installed a systemd update and when you said there was already a fix written, working it's way through the distro update systems, all I had to do was check my log.
Linux Mint makes it easy.
But why didn't you say something such as "reported to affect systemd versions up to and including 239" and then give the link to the CVE? That failure looks like rather careless journalism.
I still don't understand on what systemd, gnome3, Networkd or all the stuff shiped with most of the distribution Linux available has in some point, improved efficiency, security, and management of the system... I experienced the exact reverse of this : system unstable, bug, loss of performance and control.
Finally ended with Gentoo which is finally the easiest distribution to manage and control amd offer something the other don't : Freedom.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
