David Vasil wrote: > Hari Sekhon wrote: > >> One example in which it can be safely done is if you are limiting your >> variable to the hostname for the log and you use keep_hostname(no) in >> syslog-ng or equivalent logserver software, which should guarantee it is >> a correct ip address or hostname (assuming your DNS isn't >> compromised/intercepted if using that to resolve the hostname - another >> potential threat). >> > > The issue with this is that it is trivial to craft spoofed udp/514 packets. > Yes of course this was implied but in fact this is not really a huge security threat in the context that we are discussing regarding shell injection of variables from regex captures.
The worst this could create is misinformation. DoS shouldn't be an issue if you're using your suppression properly. >> Otherwise, pretty much the entire rest of the log is vulnerable to >> tampering through manual network insertion of logs in to the logserver >> since it has to accept logs from the network being a logserver. Also, >> > > Creating a more tamper-resistant logging environment may provide a > little more safety. Enabling SSL based tunnels for syslog[1] or signing > all syslog messages[2] can help with this goal. > Using stunnel could open a potentially hole in my opinion. To do this you end up with the choice of either having everything logged as 127.0.0.1 (useful! ;-) ) or you have to use keep_hostnames(yes) which means that anyone anywhere can now inject arbitrary strings into the hostname field of your logs as well. As I mentioned in the quoted email it is only safe to use the hostname field if keep_hostname(no) is used as you're then assured that it will be an ip or a dns name (dns disclaimer as above). If you're doing this keep_hostnames(yes) then you have to look at a generically powerful workaround to completely nullify any potential for shell metachar type abuse. I think my solution in my last email I sent just after the quoted one should cover it. > But that only protects from network attacks. Malicious local users or > poorly written programs can still inject syslog messages via logger or > other local mechanisms. Which brings us back to trying to solve the > problem by limiting what we do with the information we are provided or > sanitizing it (and possibly diminishing the usefulness of the original > information). > Yes as mentioned in the quoted email the rest of the message is still highly suspect in any event. To tackle this generically I've so far settled on my workaround of creating and piping a context body through stdin to completely circumvent variables going anywhere on any shell command line. > [1] SSL Encrypting Syslog via Stunnel: http://librenix.com/?inode=7126 > [2] Signed syslog Messages: > http://www.ietf.org/internet-drafts/draft-ietf-syslog-sign-23.txt > Useful links indeed. Thanks. -h -- Hari Sekhon ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Simple-evcorr-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
