Rooting Out Corrupted Code
Sometimes it's easy to tell when you're dealing with an imposter. That Mona Lisa at your neighbor's yard sale is unlikely to be the real thing. When you see Elvis at the mall, you can be pretty sure that he's a fake, too.
Even on a computer it can be obvious. when you run strings against your ls binary and among all of the other data it returns gcc -shared -o /tmp/own.so /tmp/own.c;rm -f /tmp/own.c, you can be pretty sure that's not the real ls command. A fellow in my local Linux Users Group reported this recently, and he didn't need to be told that the system had been rooted.
Sometimes, however, it's more difficult to tell if there's a problem. The most common way to verify the integrity of a binary on a Unix system is by comparing a checksum of the actual file to the checksum of a known-good copy of that file. Tripwire and AIDE are popular system validation tools built on this premise.
The checksum concept has its roots in the bad old days of 300 baud modems without built-in error correction, the xmodem protocol guarded against downloads corrupted by line noise. On the sender's side, xmodem would break a file up into 128-byte chunks and run a check against each block that would produce a single number. After downloading a block of data, the receiver's system would run the same check against it. If both sides got the same answer, the receiver would ask for the next block of data; if the answers differed, then the receiver asked the sender to retransmit the corrupted data.
[ Read more ]
By subscribing to our early morning news update, you will receive a daily digest of the latest security news published on Help Net Security.
With over 500 issues so far, reading our newsletter every Monday morning will keep you up-to-date with security risks out there.