821–830 of 862 posts
Earlier quoted context omitted.
Well step one is to just stop doing it? I guess someone will need to start publishing a static-only linux distro
I think you don't fully understand how the attack works. Had sshd been written in go or rust, the attack would have still been possible.
Earlier quoted context omitted.
This particular approach of hooking would be much harder; but a malicious xz has other options as well. It's already in the code path used by dpkg when unpacking packages for security updates, so it could just modify the sshd binary, or maybe add a rootkit to the next kernel security update. It seems foolish to change our systems to stop one of the steps the attacker used after their code was already running as root;…
There are other reasons to change, though. The main thing to consider here is that static linking is the "OG" way of doing things, and also the simplest and the most easily understandable one. There are also obvious perf benefits to it when it comes to optimizing compilers. On the other hand, dynamic linking was originally more or less just a hack to deal with memory-restricted environments in the face of growing amo…
In the event that exploit code has already been deployed, while these exploit attempts should now thankfully be futile, is there any valuable information that can be gained about the network sources of these exploit attempts?
We might assume that since this attack was foiled, exploit attempts won't happen, but if this is an automated botnet project, there may already be other operational elements in the wild that are knocking?
It's possible that there is an infection detection component to the project which is already measuring baseline accessibility, possibly using this and several alternate vectors. After all, effort was made to evade exploit attempt detection which would enable valuable active monitoring since it shouldn't trigger suspicions.
Earlier quoted context omitted.
I think drunk driving being an oil that keeps society lubricated cannot and should not be understated. Yes, drunk driving kills people and that's unacceptable. On the other hand, people going out to eat and drink with family, friends, and co-workers after work helps keep society functioning, and the police respect this reality because they don't arrest clearly-drunk patrons coming out of restaurants to drive back hom…
This is such a deeply American take that I can't help but laugh out loud. It's like going to a developing nation and saying that, while emissions from two stroke scooters kills people there's no alternative to get your life things done.
And no, there is currently no substitute for a legal removal of your repression so that you can, say, get on with some shagging. I would love to see a study trying to determine what percentage of humans have only come into existence because of a bit of "social lubrication"
For some people, alcohol is indeed "medicinal".
Earlier quoted context omitted.
Except they weren't irresponsible. We all drove back just fine, and we all went back to work just as competently as before like nothing happened. It takes skill and maturity to have a good time but not so much that it would impair subsequent duties. The French demonstrated to me they have that down to a much finer degree than most of us have in America, so they have my respect. This isn't to say Americans are immatur…
As someone who knows people who died in a crash with another drunk driver, it is hard for me to accept your view. Certainly, at a bare minimum, the penalties for drunk driving that results in fatality should be much harsher than they are now -- at that point there is hard empirical evidence that you cannot be trusted to have the "skill and maturity" necessary for driving -- but we can't even bring ourselves to do tha…
I think the real problem is that people are really poor at assessing risk. And I think we can make some headway there, educationally, and it might actually affect how people reason around drunk driving (or their friends, assuming they still have their faculties).
Let's take the example of driving home drunk without hurting anyone or having an accident. Suppose that (being optimistic) there's a 1% chance of an accident and a 0.1% chance of causing a fatality (including to self). Seems like an easy risk to take, right? But observe what happens if you drive home drunk 40 times:
99% chance of causing no accident each time, to the 40th power = 0.99^40 is roughly 67% chance that none of those 40 times results in an accident. 80 times? 45% chance of no accident. Now you're talking about flipping a coin to determine whether you cause an accident (potentially a fatal one, we'll get to that) at all over 80 attempts. (I feel like that is optimistic.)
If I have a 99.9% chance of not killing someone when drunk-driving one time, after 80 times I have a 92% chance of not killing someone (that is, an 8% chance of killing someone). Again, this seems optimistic.
Try tweaking the numbers to a 2% chance of an accident and a 1.2% chance of causing a fatality.
Anyway, my point is that people are really terrible at evaluating the whole "re-rolling the dice multiple times" angle, since a single hit is a HUGE, potentially life-changing loss.
(People are just as bad at evaluating success risk, as well, for similar reasons- a single large success is a potentially life-changing event)
Earlier quoted context omitted.
Because in the closed source model the frustrated developer that looked into this SSH slowness submits a ticket for the owner of the malicious code to dismiss.
This seems completely unrelated to the grandparent comment’s mention of open source LLMs
> Imagine a future where state actors have hundreds of AI agents fixing bugs, gaining reputation while they slowly introduce backdoors. I really hope open source () succeed.
I guess we can only hope verifiable and open source models can counteract the state actors.
Earlier quoted context omitted.
Why does it have to be russian? Could be any country, even USA, China. I don't see why this sort of attack is limited to Russia.
> Why does it have to be russian? Could be any country, even USA, China. Are you sure you are replying to right comment? Because they did not implied it was not other country or actor. It even directly starts with 'IF'.
if russian -> could be ...
why would being russian make it this? it could be if it was made in any country. they did this attack once, okay? but its not like other countries dont pay attention.
Earlier quoted context omitted.
systemd is just fine on Arch without this patch. It's not a systemd issue, it's a larger cultural issue with packagers increasing attack surface to make their lives easier.
It absolutely, positively, 100% was added due to issues with systemd. Both Redhat and Debian and others applied this patch as a result. People didn't do it "just cause". https://bugzilla.redhat.com/show_bug.cgi?id=1381997 Jakub Jelen 2016-10-12 08:40:44 UTC > Why do you want to avoid sd_notify()? Why to avoid this? Well, it is adding more systemd-specific bits and new build dependency to something that always worked…
Earlier quoted context omitted.
I think the criticisms of systemd are valid but also tangential. I think Poettering himself is on one of the HN threads saying they didn't need to link to his library to accomplish what they sought to do. Lzma is also linked into a bunch of other critical stuff, including but not limited to distro package managers and the kernel itself, so if they didn't have sshd to compromise, they could have chosen another target.
And yet: https://news.ycombinator.com/item?id=39878181 So no, as Pottering claimed, sshd would not be hit by this bug except for this systemd integration. I really don't care about "Oh, someone could have written another compromise!". What allowed for this compromise, was a direct inability for systemd to reliable do its job as an init system, necessitating a patch. And Redhat, Fedora, Debian, Ubuntu, and endless oth…
That said, there are dozens of ways to fix this and it really seems like RedHat chose the worst one. They could have patched sshd in the other various ways listed in that ticket, or even just patch it to exit on SIGHUP and let systemd re-launch it.