Too weak
Too weak
Posted Dec 11, 2003 12:31 UTC (Thu) by walles (guest, #954)Parent article: Lessons from the Debian compromise
IMO this article was far too weak. "Crackers can make bad code" is not something you should rely on. I agree on the bio-diversity point. "Good people make a difference" might be true, but it is too weak. How do you get "good people" to run your system? Especially if you are a home user?
What should be learned from this is stuff that people can actually *do* something with. Like the bio-diversity, the attack was obviously somewhat contained by Debian using more than one hardware platform.
I think the real question that should be asked (I don't have the answer unforturnately) is:
"Imagine there is an unknown, exploitable bug in the kernel's brk() implementation. What *technical measures* (other than discovering + fixing the bug) could prevent that problem from being exploited?"
Answer that, and this won't happen again.
BTW, I haven't heard anything about the Stanford Checker lately, could something like that have found the bug in the first place? If so, that program should be run every time somebody checks something in into BK.
Posted Dec 11, 2003 16:36 UTC (Thu)
by RobSeace (subscriber, #4435)
[Link] (2 responses)
Forbiding all remote user access would do it... But, may be too extreme So, all this continued focus on the kernel brk() bug really bugs me... (No
Posted Dec 13, 2003 19:05 UTC (Sat)
by giraffedata (guest, #1954)
[Link] (1 responses)
That's because there are all kinds of legitimate reasons for having a system that untrusted people can log into as an unprivileged user. We should not therefore squander our attention on stopping people from logging in, but rather allocate it to stopping privilege escalations.
Posted Dec 13, 2003 19:49 UTC (Sat)
by RobSeace (subscriber, #4435)
[Link]
By having access to the developer's user account, the attacker can pretend Gaining root, when you already have the above power, is just unecessary
> "Imagine there is an unknown, exploitable bug in the kernel's brk() Too weak
> implementation. What *technical measures* (other than discovering + fixing
> the bug) could prevent that problem from being exploited?"
>
> Answer that, and this won't happen again.
for many... ;-) People seem to forget, it's NOT the kernel brk() bug that's
ultimately to blame here, as I see it: that was just a local exploit, which
allowed the attacker to escalate their privs once they'd already broken into
a normal user account... The REAL problem is that they broke into a normal
user account, in the first place! Do you imagine the impact of that, even
without root access, to be a minor issue?? (I mean "you" in the generic
sense here, not attacking you personally...) If this person whose account
was compromised was a developer (and, if not, why do they have an account
on those machines??), then all an attacker would NEED is their normal user
access in order to plant trojan horses in any software the developer had
access to... Plus, by pretending to be that user, they could perhaps
social-engineer others into giving them enough info to do further damage,
elsewhere...
pun intended... ;-)) It's completely missing the point to lay the blame
there, and give THAT all of the focus and attention... It would be much
more important to focus on how the person got access to that user's account
in the first place... THAT is what needs to be prevented in the future;
and, that's FAR more important, IMHO, than any local-only root exploit...
If no one untrusted has remote access, then all local exploits become
totally irrelevent... And, even in the case where there were no local
exploits at all, letting anyone untrusted have remote access to a legit
user's account is STILL a very, very BAD thing... So, as I say, I think
everyone is focusing on the wrong problem in this whole mess... ;-/
I take the opposite view. An unauthorized user being able to log into a system as a nonprivileged user is a small deal. Being able to escalate to a privileged user is a big deal.brk() bug was the real problem
How on Earth can you say that someone gaining access to a legit developer'sHow do you figure??
user account is "a small deal"???? And, at the same time, that going from
there to root is a "a big deal"???? I can't comprehend your perspective...
to be the developer, including doing such things as checking in code under
his/her name, communicating with others to obtain info intented only for the
developer, and basically anything and everything that legit developer could
do... Is this really "a small deal" to you???? Do you realize the damage
that could be done this way?? Think about it... Chances are, no one would
ever have found out about such a user-only attack: no system files would
have changed, no kernel oopses as warnings, nothing to tip anyone off that
anything was up... So, this person could have undected access for as long
as they wanted, and do anything they wanted in the real developer's name,
without arousing anyone's suspicions... They could get a hidden backdoor of
some sort worked into some major bit of software which they know will be
run by everyone that uses the distro, and as soon as it gets distributed
widely, they'd have access to thousands of machines around the world, with
no one being the wiser (until they eventually slip up and get caught)...
You don't think this represents a scary scenario?? Yet, you find the mere
escalation from an authorized remote user account to root the end of the
world???? I'm totally baffled by that...
overkill, really... If the person who pulled this off were smart, they
would've done as I describe above, and stayed hidden, and been able to do
lots of nasty things for a LONG time, before anyone ever caught them...
By being greedy and going after root, they got caught quickly... And, what
did it gain them?? Not much... Seriously, tell me: what are you so afraid
they could've done as root, that they couldn't have accomplished far more
stealthfully as the developer?? It seems to me the big danger is planting
some kind of back-door/trojan into the source, right? Why do that with
noisy root access, when you can do it with stealthy developer access, and
arouse no one's suspicions?? Sure, as root they can sniff everyone's
passwords and monitor everyone's communications, etc... But, so what?
What is the ultimate danger from doing that: that they'll be able to find a
way to poison the source code, right? Or, are you worried about some OTHER
danger that I'm not seeing??