Slashdot Mirror
Trojan Found in libpcap and tcpdump
msolnik writes "Members of The Houston Linux Users Group discovered that the newest sources of libpcap and tcpdump available from tcpdump.org were contaminated with trojan code. HLUG has notified the maintainers of tcpdump.org. See our reports here or here."
And if I don't remember, this happened befrore. Of course this is one of the biggest strenghts of the Open Source Model.
Code is constantly audited, checked and corrected. If your closed source software has backdoors or trojans...well....who knows but on Open Source is easyly detected.
Use them.
"I'd rather have a full bottle in front of me than a full frontal lobotomy"
Isn't this one too many?
There was dsniff, BitchX, OpenSSH etc. and today tcpdump and libpcap?
Does anyone else think that someone has found a security hole in a popular unix daemon and is having some fun with it before notifying the authors. Or maybe there is a *VERY NASTY* exploit circulating privately?
At least that's what I think.
there's no-one to pay me to pay my staff for the lost man-hours caused by this
Did Microsoft pay you for lost man-hours when your staff battled Nimda or Code Red? Didn't think so.
The good blackhats have lots of compromised machines at their disposal, and are generally way too clever to leave such an obvious clue behind.
It's possible that this guy has something to do with it, but it's more likely that his machine is owned by the same person who managed to put the trojan out there.
If some malicious coder could upload manipulated software, do you not think they could also spoof the MD5 sum also? From what I've seen, the checksum is usually just stored in a text file in the same directory.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
The trojan code seems somewhat complex and unreadable at first glance. The variable names don't express much of the semantics. It even doesn't have any comments. No wonder no one notices if this kind of stuff is written into code. And this is very clear code.
/* Here's stuff for the trojan. */, but if all code is well documented, it's generally easier to understand and intentional obfuscation might be easier to spot.
Even (or especially) free software developers should use more descriptive variable names and comment their code well. It makes the code much more readable for analysis, both security or quality reviews.
Well, ok, crackers probably want to obfuscate their code with
I'd recommend the rule: "One comment per statement, except when really unnecessary." Many people think it's silly, but those people haven't had to read a lot of other people's code.
Hmm, I wonder why they used port 1963...author's birth year? Nah, that would be too old for a typical cracker.
"It's the one problem with the open-source community - there's no-one to pay me to pay my staff for the lost man-hours caused by this. "
And this is different from Closed Source how ?
Doesn't the money come from the money you`ve saved by not having to pay for any software? What did your business plan mention about this? Just a blank page, right? Try it out and see what happens? Well, it's your money!
Same place it will come from if you use Closed Source software, using Open Source products does not mean zero cost IT, it means lower cost IT. If your company did plan for these things, then it will make no difference what products you are using.
Fascism should more properly be called corporatism, since it is the merger of state and corporate power - Benito Mussoli
The reason this is a problem is that nebulous shrug of an answer to the question "Who are you trusting to provide this code which you execute?" It could be an anonymous PGP/GPG key, but to violate people's trust would mean that trusted token is no longer trusted, and thus it would identify the other risks out there.
Imagine the tcpdump distributions were signed by an anonymous key. We could look over the code, and decide to trust that key. Later, people would be able to tacitly trust that key to sign tcpdump tarballs. One day, the tcpdump code will fail to match the signature: it will be caught before being executed, and the trojan will be discovered quickly. Later, another trojan will appear, but the signature will match. A few people will be bit, but the key will be exposed and others will be able to quickly identify their risk.
At the VERY LEAST, use MD5 sums on the files like FreeBSD ports!
--- Nothing clever here: move along now...
I think the worst thing is that the server the trojan connects to is still operating :
$ nc -vvv 212.146.0.34 1963
mars.raketti.net [212.146.0.34] 1963 (?) open
M sent 0, rcvd 1
The program connects to 212.146.0.34 (mars.raketti.net) on port 1963 and reads one of three one byte status codes:
A - program exits
D - forks and spawns a shell and does the needed file descriptor manipulation to redirect it to the existing connection to 212.146.0.34.
M - closes connection, sleeps 3600 seconds, and then reconnects
maybe someone should contact the machine administrator before more people get owned.
ex$$
This apparently misleading (albeit well-intentioned) comment gets modded +4 interesting, meaning that almost everyone will see this poor guy's name.
/. An early poster makes assumptions and gets modded way the hell up, then all the rebuttals pointing out he's talking out of an unreliable orifice wallow in the low point range.
All the replying posts pointing out that it's a phone company/ISP and it's almost certainly nothing to do with this chap are at 2 or below, meaning that many people won't see them and this individual's name is now besmirched.
And, by the way, this happens all the bl**dy time on
Yeah, I know it's off-topic. Just wanted to rant about something that irritates me. Return to your normally-scheduled bits and pieces.
1. Just grab the source and build it. This is no better than grabbing a binary and running it, as far as security goes.
2. Grab the source, check the MD5 sum, and then build it. This is no better than grabbing the binary, checking the binary's MD5 sum, and then running it.
3. Grab the source, diff it against the previous source you were running, and at least glance at the diffs to see if anything looks suspicious. This is the only way that using source gives you more security than using the binary.
People using source for security who are in category 1 or 2 are just fooling themselves.