Turn off Apple Intelligence on macOS 27 and get its disk space back
Thread
Unofficial Hacker News client; not affiliated with Y Combinator.
Turn off Apple Intelligence on macOS 27 and get its disk space back
Unofficial Hacker News client; not affiliated with Y Combinator.
arialdomartini · · focus · HN ↗
<a href="https://nocurlbash.com/#en" rel="nofollow">https://nocurlbash.com/#en
porridgeraisin · · focus · HN ↗
curl | bash scripts all define a function and then call it on the last line. This is a non issue in the real world.
> The server knows you’re piping — and can lie
This `sleep` based trick is always a cool demo to show freinds yes, but the server can also sneak in malware in a multitude of other ways given you're downloading code and binaries from them.
> You trust DNS, TLS, the CDN, and the origin simultaneously. A compromised CDN or BGP hijack delivers malware silently.
Well yes, that's how the internet works. If TLS of the server is really compromised, then the attacker will replace the checksum as well as the signing key. In real scenarios, you are going to be reading the signing key and checksum from the same domain. [1]
> You can’t reproduce what ran
`| tee inspect.sh | bash`
> Add sudo and it’s game over
Most credentials and important files live in the home directory, root is a red herring. If you're running it on shared server, then well... don't add sudo.
[1] Yes of course there are legitimate usecases for signing software. Common example: linux distros which are mirrored at many domains, but the checksum and signature are hosted on the canonical domain. But if I am curlbashing uv's install.sh from `astral.sh`, then doing signature verification using the public key hosted on the same astral.sh isn't adding much.
Terr_ · · focus · HN ↗
The problem is that:
1. The effort and care needed to test is unnecessarily high. You've got to guard against way more tricks from an interactive source that can see you and choose what it's going to deliver and how.
2. With no "standard" artifact that can be exactly compared, that work cannot be shared.
In contrast, release_1.2.3.zip isn't going to mutate under you and everybody can agree on what its size/hash/bytes ought to be, and if it deviates from that it sets off alarm-bells.
> curl | bash scripts all define a function and then call it on the last line. This is a non issue in the real world.
Why would a convention often followed by good/careful actors bind what malicious/careless people create?
porridgeraisin · · focus · HN ↗
Terr_ · · focus · HN ↗
Consider this analogy: You need to meet a stranger to get their signature on a legal document, and the stranger could be a rapist murderer. Which option sounds better?
1. Meet them in a crowded convention center with cameras.
2. Meet them alone in an abandoned building.
Sure, they could whip out a knife and stab you in either situation, but the difference is not a "lost cause." If they have any rationality, the public place deters them because the risk of being detected and caught is higher.
> I don't see what the zip file adds.
A process based on public single-signature releases means that the author must choose to either release something benign to everyone, or malicious to everyone. Even if the shared artifact has sneaky covert logic to trigger in only some environments, the logic is detectable in everyone's copy.
In contrast, this bad curl-to-bash process means a savvy villain could give a perfect veneer of respectability to the world at large, while sending tailored attacks to a minority of visitors, even a targeted minority. Their risk of detection is way lower. Not only that, but victims who follow the flawed process will lose some of the best clues for figuring out who hacked them later.
porridgeraisin · · focus · HN ↗
That can also be done with a if statement in the actual code as well.
Per your analogy, no point of a public place if it's as easy for the guy to give you a package that can explode when you get home in either case.
Terr_ · · focus · HN ↗
I reiterate: "Even if the shared artifact has sneaky covert logic to trigger in only some environments, the logic is detectable in everyone's copy."
Moving that if-statement to a hidden remote server is both significant and worse for security.
> Per your analogy, no point of a public place if it's as easy for the guy to give you a package that can explode when you get home in either case.
Hold up, if you're going to mutate the metaphor like that, then the nearby crowd becomes other people also getting packages.
I refuse to believe you don't have a clear preference between:
A: You want a standard product. You get a package that might be secretly "personalized" for you by the dodgy sender.
B: You want a standard product. You get a package which you know is identical to 10,000 other packages being given out... Many of which have already been taken to homes, with no reports of explosions or strange devices inside.
_____
The analogy-free basics are:
1. Consistency of behavior is important for good security, and curl-to-bash is bad that way.
2. Shared visibility of what actors do is important for good security, and curl-to-bash is bad that way.
3. Those are important to security because they deter and limit what malicious actors can attempt or get-away with.
porridgeraisin · · focus · HN ↗
Fair enough, I guess I don't agree that that difference is significant. I can't imagine logic that doesn't trigger at all for most people being detected in any reasonable way.