Top
Best
New

Posted by psxuaw 14 hours ago

Maybe you shouldn't install new software for a bit(xeiaso.net)
597 points | 324 commentspage 3
golem14 10 hours ago|
This gets me to ask whether I have been hacked . For a few weeks now, both my main mbp and iPhone have been showing unexpected hangs of 1-30 seconds. I can’t find out what’s causing it - not memory pressure, not cpu load.

I am worried that the sluggishness appeared about the same time on both devices

Gigachad 9 hours ago|
For ios, rebooting your phone is extremely effective at removing exploits. The boot chain attestation stuff can verify the system is in a known state. If you are ultra paranoid you could enable lockdown mode which preemptively disables the entrypoints for exploits. So far I don't believe there has been any exploit which works with lockdown mode enabled.
Georgelemental 8 hours ago||
If you are already exploited though, I doubt it helps
jeroenhd 7 hours ago|||
Getting persistent root is actually quite difficult on mobile operating systems. iOS famously so, but unless you're running a custom ROM other than Graphene, Android has some solid protections as well.

Regular phone reboots are a security measure at this point.

Gigachad 7 hours ago|||
It does though, the exploit exists in memory. When you reboot the phone the memory is reset, if it's modified system files, the checksums won't pass and your phone will refuse to boot. Requiring it to be wiped and reinstalled.

These days most exploits can not persist through a reboot due to secureboot and other bootchain attestations. In the boot process, everything loaded gets checksummed and compared to signed signatures from Apple, but this only helps at load time, not while the phone is running. Of course if the phone is not patched, the exploit could be reloaded, but this would require revising a malicious website or reopening a malicious bit of media.

1a527dd5 5 hours ago||
This applies to much more than just software, in fact it applies to almost everything.

I don't remember where I read it, but it basically boils down to need vs want.

I've used that rule for deciding between a new car or used. A fancy vacuum or basic.

A shiny new gadget.

Bringing new things into the tech stack.

Picking a new tech stack.

mobeigi 4 hours ago||
I saw a recent post about only adopting packages a certain number of days post release (say +3 days, or +7 days) after. The idea is you never bring in fresh commits, only older ones. This would need dangerous or bad commits to be marked vulnerable too.

It means you skip supply chain attacks but may miss fresh vulnerability patches too.

KevinMS 11 hours ago||
I got rid of half of my VSCode extensions a couple days ago, its too risky.
BobbyTables2 10 hours ago|
Those things scare the crap out of me…

Even worse are the “extension packs” that combine some normal things and one wonky thing nobody’s ever heard of…

femiagbabiaka 13 hours ago||
Yes, and, for non-personal machines or anything connected to the internet: now is a great time to get good at rolling out patches and new releases quickly.
Gigachad 9 hours ago|
The proof of concept code is out before patches are available for any distro.
leonidasv 11 hours ago||
The post is about Linux vulnerabilities, but given the recent supply chain attacks, I'd be especially careful with Homebrew: https://x.com/i/status/2052106143271354859
nomilk 11 hours ago|
Often convenience and security are at odds, but `export HOMEBREW_NO_AUTO_UPDATE=1` is more convenient and more secure.
cromka 5 hours ago||
Problem here is Brew does things in an anti-unix way by default, the auto updating of packages being the prominent reason.

I personally switched away from macOS with this being one of the reasons, after having realized brew will eventually compromise my system with their antics.

yurug 5 hours ago||
At some point, some people will rebuild an entire stack (all layers, from OS to applications) with proof carrying code upgrades. Proof-code co-design and co-construction is the only way to execute code that you can trust.
alecco 4 hours ago||
Or disable algif_aead module as in https://news.ycombinator.com/item?id=47957409
JetSetIlly 4 hours ago|
That's not enough in this case. The suggested mitigation according to the Dirty.Frag github page is to blacklist esp4, esp6 and rxrpc
alecco 3 hours ago||
Thanks.

Discussion https://news.ycombinator.com/item?id=48054182

pjmlp 8 hours ago||
Remember the whole discussion when UNIX was supposed to not need anti-virus and talking down PCs?

Behaviours matter more than OS security primitives.

jeroenhd 7 hours ago|
The whole (mistaken) belief that Linux and macOS didn't require AV was based on the execute bit being present, something Microsoft fixed back in XP by making downloaded files as such and preventing them from being opened trivially.

If you have code execution, you can attack the OS.

pjmlp 6 hours ago||
Indeed, when one installs dependencies all over the Internet, or even better, key projects use "curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh" as default suggestion on how to install them, attackers have the work done for them.
1718627440 4 hours ago||
> key projects use "curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh" as default suggestion

This is exactly why some (including me) don't take these projects seriously. Like you claim to design a language for security, and this is how you tell me to install it????

pocksuppet 14 minutes ago|||
Downloading some code from the internet and running it is a very normal way to install software.

curl|sh has the truncated shell script concern. It's possible to mitigate this concern. Did they? If so, it's no different from downloading and running any other installer.

TeamDman 41 minutes ago|||
What alternative do you propose for downloading binaries off the internet, placing them in the "right spot" and doing post-install operations like updating PATH that dont have gotchas equivalent to running "untrusted" code like curl|sh?
chubs 8 hours ago|
To mitigate supply chain attacks like this, I've taken to specifying exact versions in my Rust cargo.toml, and when importing new crates, select the previous-to-latest version. Is this a reasonable mitigation? It bugs me that Swift deprecates the concept of specifying exact versions, it actively pushes you towards semver which leaves the door open to this.
kam 13 minutes ago||
Cargo will still pick the latest for transitive dependencies that aren't explicitly specified in your Cargo.toml. This is what Cargo.lock is for.
mattstir 29 minutes ago||
> select the previous-to-latest version

For supply chain attacks that simply bide their time, or for dependencies which involve interacting with other subsystems, it's possible you miss a critical security update by doing this. Of course, the maintainers of the crates should yank known bad releases, but that's putting trust in a third-party that may have already been compromised.

More comments...