Known-exploit detection for the kernel

Posted Dec 19, 2013 16:25 UTC (Thu) by tshow (subscriber, #6411)
Parent article: Known-exploit detection for the kernel

It seems to me that rather than just sending something to syslog, this would be more useful if it could feed into userspace hooks and things like firewall rules. If I could rig exploit() to:

if(user is nonlocal)
{
log them out & lock the account
add their IP to the ban list
send the admin a "user tried exploit" message
}

I could see that being useful. Obviously there's potential pitfalls (people boobytrapping each other, or managing to get daemons kickbanned if the system isn't smart enough), but a tripwire hooked to a nuke can be a useful line in a layered defense.

Known-exploit detection for the kernel

Posted Dec 19, 2013 18:09 UTC (Thu) by RobSeace (subscriber, #4435) [Link] (5 responses)

Sounds like something better suited to a userspace daemon parsing the kernel log messages and acting on them... Sort of like "Denyhosts" does now with failed SSH logins...

Known-exploit detection for the kernel

Posted Dec 19, 2013 20:35 UTC (Thu) by tshow (subscriber, #6411) [Link] (4 responses)

That's what I'm implying; it would be nice if this could export via some sort of file descriptor through which you could feed a userspace daemon, rather than shuffling stuff off to the logger. Logging is great, but if there's an exploit attempt I want to deal with it now, not after something gets done parsing the logs.

Known-exploit detection for the kernel

Posted Dec 19, 2013 20:45 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

you can feed it to your userspace daemon through syslog pretty darn fast, how fast do you think it needs to be acted on? and are you talking about an automated action or a manual action? if it's a manual action, the time taken to get a human's attention is FAR longer than the delay that syslog will introduce.

In addition, I'm not sure this is something you want to jump on every time (that the reason for rate limiting the alerts), you may just get flooded with alerts.

Known-exploit detection for the kernel

Posted Dec 20, 2013 16:21 UTC (Fri) by tshow (subscriber, #6411) [Link] (2 responses)

I'd want it for automated response, with a subsequent notification to the admin that the automated response has been made.

If someone is script kiddying their way through a series of exploits to see what sticks, I want the userspace daemon to be able to log them out and ban their IP (and possibly lock their account) *now*, this microsecond, before they get a chance to try the next one. Yes, that does imply potential scheduling hackery to get the data out the exploit alert pipe to the userspace daemon before control is allowed to return to the offending process.

In theory you'd only get flooded with alerts if the system was flooded with exploit attempts. You'd probably want to know if that was happening, but rate limiting could be done in the userspace daemon.

I think you'd want to be able to differentiate between local and remote exploits; if someone logged in is trying an exploit it's a very different kettle of fish from someone trying a remote exploit against the external interface.

Feeding the userspace daemon through syslog is kind of silly; a dedicated pipe the daemon could connect to would be better. Avoiding syslog as a transport means:

- being able to specify a consistent communication protocol
- possibly being able to avoid parsing entirely, but at the least the protocol can be designed to make the parsing trivial
- not needing to worry about some other syslog output source being tricked into spoofing valid-looking but manufactured exploit logs
- the daemon being able to sleep on data availability in the pipe rather than having to constantly chew on syslog and spit out the (1 - epsilon) it doesn't need, so the daemon will mostly just be asleep until its needed

Known-exploit detection for the kernel

Posted Dec 20, 2013 18:47 UTC (Fri) by dlang (guest, #313) [Link]

> I'd want it for automated response, with a subsequent notification to the admin that the automated response has been made.

There are a whole lot more tools available to do the alerting based on syslog message than there are going to be if you invent a new protocol.

> If someone is script kiddying their way through a series of exploits to see what sticks, I want the userspace daemon to be able to log them out and ban their IP (and possibly lock their account) *now*, this microsecond, before they get a chance to try the next one. Yes, that does imply potential scheduling hackery to get the data out the exploit alert pipe to the userspace daemon before control is allowed to return to the offending process.

This requires much more significant changes, and really is going to require that you put your response code into the kernel inside the detection routine.

> In theory you'd only get flooded with alerts if the system was flooded with exploit attempts. You'd probably want to know if that was happening, but rate limiting could be done in the userspace daemon.

given that the effort involved in generating the log compared to the action that triggers the log, not having this be rate limited would result in a very good DOS vector.

> Feeding the userspace daemon through syslog is kind of silly; a dedicated pipe the daemon could connect to would be better. Avoiding syslog as a transport means:

> - being able to specify a consistent communication protocol

why can't you use a consistent protocol in your syslog message?

> - possibly being able to avoid parsing entirely, but at the least the protocol can be designed to make the parsing trivial

you can make the parsing trivial in syslog as well

> - not needing to worry about some other syslog output source being tricked into spoofing valid-looking but manufactured exploit logs

you can do this inside syslog with filters today (only send to this output if the source is the kernel and the message contains blah)

> - the daemon being able to sleep on data availability in the pipe rather than having to constantly chew on syslog and spit out the (1 - epsilon) it doesn't need, so the daemon will mostly just be asleep until its needed

again, with filtering in syslog, your userspace daemon can do this today.

And as I noted up at the top, there are a lot more alerting engines around that understand syslog than ones that will understand your new protocol.

Any significant company is already going to have an alerting tool in place, it's far better to integrate with that than to require a new tool be written.

Known-exploit detection for the kernel

Posted Dec 29, 2013 8:06 UTC (Sun) by lamawithonel (subscriber, #86149) [Link]

this patch set uses the audit framework without any rate limiting, and in the somewhat more structured audit format. that sounds like what you want.

+ audit_log_format(ab, "exploit id=%s pid=%u uid=%u auid=%u ses=%u comm=",
+                  id, pid, uid,
+                  from_kuid(&init_user_ns, audit_get_loginuid(task)),
+                  audit_get_sessionid(task));

Known-exploit detection for the kernel

Posted Dec 25, 2013 23:03 UTC (Wed) by nix (subscriber, #2304) [Link] (4 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.

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.)