Closed CodingMarkus closed 4 years ago
Or you can just prepend PATH environment variable with a new directory with malicious rm
binary in it, which will shadow the system one. That's the same case as you describe, Homebrew isn't really the baddest here.
@CodingMarkus See also https://github.com/Homebrew/brew/issues/4016#issuecomment-378105207 and https://github.com/Homebrew/brew/issues/5172#issuecomment-432561456.
Please fill out the issue template next time (for non-security issues) or report security issues to our HackerOne. Thanks!
This means any malware running on my system can manipulate these binaries
To be more specific: any software running without a sandbox.
When I now run such a binary with sudo
Don't do that, then.
All that the malware has to do is to replace all binaries installed by brew with stubs
If malware has read/write access to everything as your user: they can already steal/destroy all your personal files and documents anyway.
That is why all other Linux/UNIX package systems install binaries only with root ownership, as then only a root process can alter them and such a process would already have root privileges.
MacPorts does this, it may be a better fit for you.
Don't do that, then.
Yeah, and if I don't turn on my computer, no malware can infect it. But since when is this a valid argument for anything?
Homebrew is a car without safety belts and apparently it's proud of that. And when I say "Your car is dangerous, it has no safety belts", your argument is "Then better drive carefully". Seriously?
If malware has read/write access to everything as your user: they can already steal/destroy all your personal files and documents anyway.
Yes but they cannot perform commands with root privileges, they cannot alter critical system configuration, they cannot install system services with launchd, they cannot access system files or files of other system users. If it was no problem to be root, why would the system even make a distinction and ever require root privileges?
MacPorts does this
Because anything else is irresponsible. Even if I never directly execute a tool installed by brew with sudo
, if the brew command folder is in the PATH
, some other tool or script might do so when I call that with sudo
. Basically as soon as one has Homebrew installed, you are risking to lose control of your system every time you use sudo
.
But I expected this reaction from you and personally I couldn't care less how terribly insecure Homebrew is. I plan to release an exploit directly targeting macOS itself, after I have informed Apple on time and they refused to react. The issue is not exactly the same one as with Homebrew but it's similar. And even if Apple was fixing the problem, which in fact would be dead simple to do, It would be really simple to modify my exploit and directly attack Homebrew users instead. I only opened up that ticket so you cannot say you haven't been warned in advanced in case this bomb hits you.
If you had said "Yes, you are right, this is a problem and we are working on fixing it", I would have definitely given you that chance; I'm not interested in harming anyone. I also gave Apple more than enough time to take actions or to at least show some kind of positive reaction. But with this attitude I can confidently continue without having to have a bad conscience at the end.
Just to summarize the outcome of this ticket:
Basically you say it's okay that everyone can become root on systems using Homebrew or more precisely you say "If some malware becomes root because of Homebrew, that is only the fault of the Homebrew user; s/he shouldn't have done whatever s/he has been doing". Sure, blame the user for poor design decisions, I can live with that and I'm not even one of them, so no offense taken. After all, security is so overrated these days...
I couldn't care less how terribly insecure Homebrew is.
I plan to release an exploit […]. It would be really simple to modify my exploit and directly attack Homebrew users instead. I only opened up that ticket so you cannot say you haven't been warned in advanced in case this bomb hits you.
You don’t care about Homebrew but you’re thinking of attacking Homebrew users?
I'm not interested in harming anyone.
Don't do that, then.
A few thoughts on the points you’ve made:
If it was no problem to be root, why would the system even make a distinction and ever require root privileges?
You can restrict sudo
to let users (and attackers) run only specific binaries.
Some users may not be sudoers at all.
Root privileges and sudo
act as a safeguard against accidentally breaking things.
It’s defense in depth. Privilege escalation to root is just another obstacle that can be overcome. But it’s an obstacle, and may be what deters actors to go somewhere else for some lower-hanging fruit.
What separation of privileges can’t do is keep a malicious process with user privileges from becoming root as soon as the user escalates to root.
Yes but they cannot perform commands with root privileges, they cannot alter critical system configuration, they cannot install system services with launchd, they cannot access system files or files of other system users.
Of course they can. Here’s a nice summary with lots of examples. They’re about Unix in general but most of it applies to macOS, too.
Basically you say it's okay that everyone can become root on systems using Homebrew or more precisely you say "If some malware becomes root because of Homebrew, that is only the fault of the Homebrew user; s/he shouldn't have done whatever s/he has been doing".
No malware ever becomes root because of Homebrew. Malware becomes root because:
[y]ou can never safely elevate privileges on an untrusted account.
If you had said "Yes, you are right, this is a problem and we are working on fixing it", I would have definitely given you that chance; I'm not interested in harming anyone. I also gave Apple more than enough time to take actions or to at least show some kind of positive reaction. But with this attitude I can confidently continue without having to have a bad conscience at the end.
(Emphasis mine)
I urge you to carefully consider what you’ve written. “I don’t want to hurt you but I will because I dislike your attitude” isn’t an effective way to convince others of your viewpoint and is unlikely to get you sympathy in the aftermath.
As @claui said, it you don’t want to cause harm, don’t.
If you believe you’ve found a serious exploit and that you’ve given Apple ample chance to fix it and they’ve failed to do so, consider sharing the methodology (Pawel Wylecial recently did just that) instead of setting it loose (which is of dubious legality).
If your exploit is indeed something novel that can harm Homebrew users, it would be helpful for us to see it to be able to discuss how much of a threat it is and the best way to avoid it. As it is, we’re in the dark with a vague threat directed at us. I hope you can appreciate it’s hard to reach a good resolution in those conditions.
When brew installs binaries, they belong to my user. This means any malware running on my system can manipulate these binaries or even replace their entire content with something else. When I now run such a binary with sudo (because I want to write output to a file in
/etc
, in case you need an example for why anyone would do that), it will get root privileges. That way homebrew helps malware to easily get full root access on the system.All that the malware has to do is to replace all binaries installed by brew with stubs that will call the real binary when executed as normal user but call a malware tool when executed as root and then just wait until the user calls any of the brew binaries with sudo one day. That is why all other Linux/UNIX package systems install binaries only with root ownership, as then only a root process can alter them and such a process would already have root privileges.
This is different to installing applications on macOS. Applications usually belong to the user but applications also will only run with user privileges. Running applications as root is not even possible in many cases. Running command line utils with sudo is a pretty common task, though.