I have been doing quite a bit of work with syslog recently. Having found a couple of bugs, I thought I had discovered a fundamental weakness in syslogd that affected ALL Unix flavours running syslogd today. As widespread and widely used as syslog is, I thought it worth testing. Here are the results:
When started, syslogd attaches itself to UDP port 514. Here it listens for logging information from across the network (LAN, WAN, whatever). When it receives a packet or two, syslogd dutifully processes the info in the packet and, if all is well, places the data in one of many log files. This is common knowledge, and fairly well-utilized. After all, having a central log host (or hosts) is a big part of a Good Karma security setup.
However, syslogd does not discriminate. In fact, syslogd will process information from ANY source. If the packet is properly formed, syslogd will gladly place the data in the log file with no validation checks whatsoever. This is where the weakness arises.
An attacker could easily blast your loghost (or any host, for that matter) with bogus information. The bogus information could contain false log entries. Perhaps entries stating that some other user is attempting to su to root. Maybe entries stating that the root drive is experiencing SCSI errors. Worse, perhaps the attacker simply fills your logs with the output of the chargen port. In short, the attacker can fill up the filesystem containing your logs, thus making your loghost useless. Then the real penetration attempt will begin, with nary a log entry to alert you to the attack.
Now those of you with syslog experience will say: "Sure, that's easily done. However, syslogd always logs the remote host's name or IP." True enough. This certainly rules out simple attacks based on logger or an alteration of the attacker's syslog.conf file. However, we all know how easy it is to spoof addresses. In fact, as part of the testing, I created a program to do just that. The program, called syshack, will happily send syslog packets to any host (using auth.notice as the logging facility/level pair) and will change the source address to any other host of your choosing. This tool took me all of four hours to create...and I'm even a bit rusty... ;-) With this code, I was able to make my Solaris box believe it was receiving valid syslog entries from my FreeBSD box. In fact, it was receiving the falsified log entries from my Linux box. It would have been just as easy to fill up the /var partition on a box across the Internet. Scary.
The point here is this: Guard your syslogd carefully. First, if possible, block UDP port 514 at your firewall/screening router. Next, be sure to actually peruse your logs. When is the last time you looked through your messages file? You might be surprised at what you find. Be sure to keep a very close eye on any logging hosts you may have. They can be the key to a strong defense or the beginning of an attack. The Bad Guys know loghosts exist, so be vigilant.
I have decided, for now, to release the source for syshack to CERT, AUSCERT, and some key contacts at certain Unix vendors only. I do plan on releasing the code to the members of this list in the near future. Stay tuned!
Coming soon: "A Day in the Life of a Security Bug": An article on what happens with a security bug after you report it to your vendor.