Known-exploit detection for the kernel

Posted Dec 25, 2013 23:03 UTC (Wed) by nix (subscriber, #2304)
In reply to: Known-exploit detection for the kernel by tshow
Parent article: Known-exploit detection for the kernel

The problem with that sort of thing is that as soon as it becomes popular enough that attackers can speculate that you might be running it (which is not very popular at all), it suddenly becomes a wonderful DoS tool.

Known-exploit detection for the kernel

Posted Jan 6, 2014 3:03 UTC (Mon) by speedster1 (guest, #8143) [Link] (3 responses)

> The problem with that sort of thing is that as soon as it becomes popular enough that attackers can speculate that you might be running it (which is not very popular at all), it suddenly becomes a wonderful DoS tool.

There shouldn't be much DoS potential for script kiddies to abuse if there were a reliable mechanism for automatic account-locking like tshow wanted.

On the other hand, count me among those who predict this feature will quickly become worked-around by all the popular exploit kits -- at least on any systems lacking admins who are big enough on security to be running custom kernels with generic uname info. Those admins who do tweak their uname and hide /boot /lib/modules are probably not the ones who the kernel devs need to worry about protecting from script kiddies (their custom kernels probably include grsecurity...)

Known-exploit detection for the kernel

Posted Jan 6, 2014 13:22 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

Locking an account *is* a DoS for the account's legitimate owner.

Known-exploit detection for the kernel

Posted Jan 7, 2014 2:59 UTC (Tue) by speedster1 (guest, #8143) [Link] (1 responses)

That makes no sense to me, perhaps you can explain more... are these DoS victims naive users who are running random things that script kiddies left for them? Or a daemon which has been tricked into running evil code? Either way, if a script kiddie gets to run stuff from an account, that account has been compromised and deserves to be locked out until it can be cleaned up. Maybe instead you are thinking of a way to lock out a non-compromised account with this feature?

Known-exploit detection for the kernel

Posted Jan 8, 2014 16:38 UTC (Wed) by nix (subscriber, #2304) [Link]

Imagine that someone has found a way to exploit, say, procmail, or some other daemon run on the user's behalf that accepts code from the network and is ultimately invoked from the network.

The right thing to do in that situation is probably to halt mail delivery and just queue everything -- but your proposal would lock the entire account. An attacker that can determine what accounts exist (perhaps via said exploit) could then DoS-attack the entire system trivially.

(But, of course, if they can execute arbitrary code as one user they can probably do that anyway, in about a million ways, and probably get root too. So perhaps my concerns are unjustified. It might well elevate a failed breakin, via an exploit that doesn't actually work, to a partial DoS, but I'm finding it hard to be too worried about that.)