Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security

Trojan Found in libpcap and tcpdump 486

Posted by michael from the when-your-packet-sniffer-won't dept.
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."
This discussion has been archived. No new comments can be posted.

Trojan Found in libpcap and tcpdump More

Trojan Found in libpcap and tcpdump

Comments Filter:

  • Glad I use Gentoo (Score:4, Informative)

    by rob-fu ( 564277 ) on Wednesday November 13, 2002 @08:29AM (#4658415)
    Emerge doesn't get tcpdump source from tcpdump.org, but from ibiblio.org.

    How did it get into tcpdump.org's sources exactly? The HLUG page isn't clear.

    • Re:Glad I use Gentoo (Score:5, Interesting)

      by dohcvtec ( 461026 ) on Wednesday November 13, 2002 @08:51AM (#4658602)
      How did it get into tcpdump.org's sources exactly?
      Presumably the tcpdump.org FTP server got 0wned, and the trojan was planted, but the people that found the trojan aren't the server admins - they just found it in the source they downloaded. And I doubt we will find out how the perpetrators got in, either. It would have been nice to find out in more detail what happened when the OpenBSD FTP server was compromised, but people are usually tight-lipped in these cases.

      • Re:Glad I use Gentoo (Score:4, Insightful)

        by taviso ( 566920 ) on Wednesday November 13, 2002 @09:21AM (#4658844) Homepage
        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.

    • Re:Glad I use Gentoo (Score:5, Informative)

      by elrond1999 ( 88166 ) on Wednesday November 13, 2002 @09:17AM (#4658802)
      Emerge Does get sources from TCPDump if all other mirrors are down. Excerpt from ebuild:
      SRC_URI="http://www.tcpdump.org/release/$ {P}.tar.g z
      http://www.jp.tcpdump.org/release/${P}.tar.gz"

      SRC_URI is a last resort mirror..
      Lucily the MD5 sum catched the trojan: (From the gentoo ebuild digest)
      MD5 03e5eac68c65b7e6ce8da03b0b0b225e tcpdump-3.7.1.tar.gz 428737
  • apt-get update...
    well, I have not installed these sniffing proggies, so it should be okay.
    Now it could be worse :
    If you suspect your binaries to be trjanized, you'd want to sniff your own machine but if (and it is the case) the sniffer is trojanized, then it could possible hide such "activities"...
    I actually read the article and it however seems that it was not the case here...
    phew :-)

    • Re:as soon as this evening... (Score:5, Informative)

      by Megane ( 129182 ) on Wednesday November 13, 2002 @09:14AM (#4658777)
      If you suspect your binaries to be trjanized, you'd want to sniff your own machine but if (and it is the case) the sniffer is trojanized, then it could possible hide such "activities"... I actually read the article and it however seems that it was not the case here...

      If you read the article more carefully, you will notice that the binaries aren't trojaned. This is a trojan in the build scripts only. So ironically, only the paranoids who build from source (but aren't paranoid enough to demand an MD5) got hit by this.

      • If you read the article more carefully, you will notice that the binaries aren't trojaned.

        Phew, glad to hear that, I was worried the trojaned sources actually built trojaned binaries - glad you got that cleared up for us.
        • Okay, I've been confused about this MD5 thing. Most often, the MD5s are either in a file in the ftproot, or in the readme if you've owned the server enough to stick a trojan in the source code, can't you just put in the MD5s of your altered source? I thought the main reason for checksums was to check for corrupt/missing data after the download, which was way more important in the noisy line modem days.
          • You don't seem that confused to me! :-) Your point is entirely valid, if the checksum is on the compromised FTP server, it's not going to be much help. If it's on a seperate webserver, there's a chance it'll be valid, but using a checksum, while being a quick and reasonably simple way of checking such downloads, should never be taken as a guarantee. They only thing they will guarantee, is that the copy you have on your hd is the same as the copy that's on the server. Only if you can trust the source of the checksum are they useful in such circumstances, otherwise take them with a pinch of salt.
          • Correct.


            The right way to do things is for the person who makes the release package (e.g., the tarball, or the rpm, or whatever) to digitally sign it. They should do the signing on a machine other than the web server or FTP server. Ideally, they do the signing on their development machine, which is safetly tucked away on a network that crackers can't get to.

          • Re:as soon as this evening... (Score:5, Informative)

            by kevinank ( 87560 ) on Wednesday November 13, 2002 @10:21AM (#4659373) Homepage
            Okay, I've been confused about this MD5 thing. Most often, the MD5s are either in a file in the ftproot, or in the readme if you've owned the server enough to stick a trojan in the source code, can't you just put in the MD5s of your altered source?

            To be useful the MD5 file should be signed, and the GPG key that signed it should be one that you know and trust. Even that may not be enough if the key owner can be tricked into revealing his private key, or the trojan horse can be introduced into the code on the code owners development machine, but it does add one layer of depth to your security.

            The first time I had a server hacked (mountd exploit, xmas '99) the machine details were sold on IRC, probably in exchange for credit card numbers, to a somewhat clueless Singapore exchange student who proceeded to delete all of my syslog files so that when I logged in remotely the root mailbox was full of complaints about missing logfiles. The rooted system was up for about a week, during which time it probed several thousand IPs for basic exploits, hosted an IRC channel through eggdrop (together with names of the hacker's friends and passwords), all on a machine with no rootkit installed and very little attempt to hide activity.

            Basically I got lucky the first time, and ever since then I've been paranoid, in hopes there won't be a second time. But with a smart hacker and a good root kit, I think even with my paranoia that I could miss a hacker on my machine for a long time, so I suspect it is only a matter of time before some well known developer gets hacked and has signed sources distributed with a trojan horse inside.

          • One thing that would be useful would be for the author to either GPG/PGP sign the file with the MD5 sums with a trusted signiture or sign the actual source/binary tarballs themselves. A lot of linux vendors seem to be doing this recently.

            J

      • Re:as soon as this evening... (Score:5, Insightful)

        by harlows_monkeys ( 106428 ) on Wednesday November 13, 2002 @10:13AM (#4659279) Homepage
        The funny thing about the paranoids who build from source is that, unless they actually look at the source, it doesn't gain them anything. There are three ways to build from source.

        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.

        • People using source for security who are in category 1 or 2 are just fooling themselves.
          You know that. I know that. Try telling THEM :) (Where "THEM" includes my boss, who makes me compile everything from source [and for Christ's sake, I maintain packages in the Debian archive!], but won't pay me or anybody else to actually *audit* the source, god-damnit.)
    • apt-get update...
      well, I have not installed these sniffing proggies, so it should be okay.

      Darn... apt-get even makes your box more secure than before even if you haven't actually installed the bad packages? This must be the Holy Grail! And it should be okay? Not only that you have not installed tcpdump and libpcap, what definitely makes it okay, you don't even trust apt-get to really solve your (non-existing) problem... Now I wanna join the apt-get cult... Where can I register?

      I bet you recommend penicillin over other medicine even when you got no infection! Or do you use apt-get then as well? Doesn't make any difference anyway...

      (For the record: I use Debian GNU/Linux among other stuff...)

    • if the sniffer is trojanized, then it could possible hide such "activities".
      I actually read the article and it however seems that it was not the case here... phew :-)
      From the article: Gencode.c is modified to force libpcap to ignore packets to/from the backdoor program, hiding the backdoor program's traffic.

      MD5 checks work nicely. Sure pgp in theory is better but since md5's are cached locally, and a helluva lot faster to check the chances that they will actually be used and verified are seemingly quite good.

      Which is to say in practice MD5 has caught rather a lot of these problems, and in quite timely manner.

      As irrelevant as various source-distributions (e.g. lunar [lunar-linux.org], source-mage [sourcemage.org] and Gentoo [gentoo.org]) are at present in other respects, they make a nice 'canary' in the coal mine :-).

  • Hrmm (Score:2, Funny)

    by Anonymous Coward
    Who would have thought that TCPDUMP would have crap like that in it?

  • Eventually, this would happen (Score:5, Insightful)

    by Rotten ( 8785 ) on Wednesday November 13, 2002 @08:31AM (#4658426) Journal
    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.

    • Re:Eventually, this would happen (Score:5, Informative)

      by khendron ( 225184 ) on Wednesday November 13, 2002 @08:46AM (#4658558) Homepage
      Easily detected? I wonder about this. If you look at the date stamp on the trojaned configure script, it is December 10th, 2001.

      Does that mean that this trojan has been around for almost a year before anybody noticed? If that's true, it does not meet my definition of "easily detected".

      • Re:Eventually, this would happen (Score:4, Insightful)

        by Rotten ( 8785 ) on Wednesday November 13, 2002 @08:55AM (#4658628) Journal
        Of course you have never disected a rootkited server. Nobody trust the date stamps, not even my grandmother does it.

        Have you ever changed the date of a file? It's quite easy.
        • Of course time stamps are not to be trusted. That is not the point I am trying to make.

          I am actually asking a question: how long was this trojan released before it was discovered? I, personally, do not know. I was hoping somebody else could tell me the answer.

      • Re:Eventually, this would happen (Score:5, Informative)

        by r55man ( 615542 ) on Wednesday November 13, 2002 @09:37AM (#4658952) Homepage
        Does that mean that this trojan has been around for almost a year before anybody noticed? If that's true, it does not meet my definition of "easily detected".

        I downloaded libpcap/0.7.1 from tcpdump.org on September 2 of this year (just 2 months ago), and it was not trojaned (I keep a record of md5 sums, and was able to check this just now).

        Probably whoever modified the file just touched it to resotre the original timestamp. This is trivial to do.

    • Re:Eventually, this would happen (Score:2, Interesting)

      by Anonymous Coward
      This argument can of course be reversed: Because sources are open, one can insert trojans.

      So there's no point mentioning it.

      The point is: When was the specific change added? By whom? The maintainer should know. Let us know. Then put the person who sent in the patch with the trojan in a black list so his/her future patches to open source programs are first severely checked, if accepted at all.

      That's more like it -I think-.
      • It should be easy to find this person. The trojan downloads evil code from a specific web site. This site is either the perps or was cracked by the perp. They will be hunted down.

        There is virtually no way to be absolutely certain of the integrity of any code, unless you audit it yourself. Even fans of OpenBSD have to admit that they are trusting the OpenBSD auditors. Some would use this to argue that you can place greater trust in closed code. But, to use Microsoft as an example (but not to claim that they are the adminstrator of all evil), the infamous Word macro virus first appeared on a Microsoft beta release and I seem to recall a story a little over a year ago about Russian hackers having spent a few merry weeks in the Windows 2000 source code. Trust now?

        The point is that we all use code on faith. Even should Palladium become reality, you are just transferring trust to another party. The lesson I think we in the Free Software community should take away from this is that we should make better use of the tools we have. We should should provide GPG signed MD5 checksums of all of our "official" tarballs. Some projects do this, some do not. As I just pointed out, this is not a guarantee, but it does provide a chain of accountability.

    • Re:Eventually, this would happen (Score:5, Insightful)

      by Bruce Perens ( 3872 ) <bruce@perens.com> on Wednesday November 13, 2002 @10:41AM (#4659604) Homepage Journal
      In handling the press and public perception for this, it's important that we make the point that binary programs are trojaned all of the time. In fact, most viruses have as their sole purpose the modification of binaries to insert a trojan copy of the virus into the binary, and to execute the virus payload. Much proprietary software has been distributed in infected state.

      The difference is that with Open Source you have an additional means of detecting the corruption - not only by its effects (as with the binary), but by reading the source.

      Bruce

  • Seems (Score:2, Informative)

    by jamesjw ( 213986 )

    Seems now more than ever the need to check the authenticity of your sources before installing.

    As if security auditing wasnt a big enough headache already :(

    • Re:Seems (Score:2, Redundant)

      by Marx_Mrvelous ( 532372 )
      You mean you don't check the checksum before you install software now? There's a reason that they provide the md5 for the compressed code!

      • Re:Seems (Score:5, Insightful)

        by paranoos ( 612285 ) on Wednesday November 13, 2002 @09:01AM (#4658664)
        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.

      • Re:Seems (Score:2, Insightful)

        by fitten ( 521191 )
        md5sum doesn't guarantee anything other than saying that the version you downloaded was the one that the author/host put out there for you to download (and not someone else's). If the author/host put a trojan in it, the md5sum will be for the trojan'd software.

        In the end, it still comes down to whether or not you (can) trust the author/host.

  • This Trojan thing... (Score:2, Interesting)

    by Big Mark ( 575945 )
    It's not unusual at all in the Unix world. Pete's sake, K. Ritchie (he who invented Unix and C, or at least part of the team) put trojans into early versions of cc and login so that he could get accsess to _any_ unix system.

    It worked with the trojaned compiler making bent versions of the login program. You couldn't detect it as if you compiled another version of cc or login from clean source the bent cc would infect that one and the cycle of infection continued. Very cleverly done.

    Actually, for all you know maybe every version of gcc ever allows RMS and Torvalds into your box...

  • Ewww (Score:2, Funny)

    by segfault7375 ( 135849 )

    Trojan Found in libpcap and tcpdump

    I swear, some of these source trees are worse than the canals of Venice. :)

  • MD5 checksums (Score:4, Insightful)

    by Zayin ( 91850 ) on Wednesday November 13, 2002 @08:35AM (#4658464)
    Use them.

    • Re:MD5 checksums (Score:5, Insightful)

      by diamondc ( 241058 ) <<gabrielfm> <at> <yahoo.com>> on Wednesday November 13, 2002 @08:41AM (#4658521) Homepage
      if someone breaks into an ftp server, they might as well replace the md5 signatures, too. a better solution would be signing the sources with a gpg key.

      • Re:MD5 checksums (Score:3, Interesting)

        by KjetilK ( 186133 )
        ....and replace the GPG signatures with keys that just have the same name and address. If there are two keys with the same name and address, which one would you trust?

        We need to come together and paaaaaarty! [cryptnet.net] :-)

        Really, that's the only solution to this problem. Probably, this is something we are going to see more frequently, so frequently perhaps that it may undermine the free software community's credibility. Therefore, we must come together and meet, and exchange signatures, so that at least we can ensure that they software is signed by its maintainer.

        Now, go and get registered at Biglumber [biglumber.com], sign up to the keysignings list [alt.org] and start organizing keysigning parties. Also, make sure that you meet other hackers when you're out travelling.

    • Re:MD5 checksums (Score:2, Interesting)

      by AccUser ( 191555 )

      That's good if you can assure that the MD5 checksum is for the original tarball. What if the guy who placed the torjan placed a new MD5 checksum as well?

    • NO!!!! NO!!! NO!!! (Score:5, Informative)

      by AxelTorvalds ( 544851 ) on Wednesday November 13, 2002 @09:34AM (#4658934)
      md5 checksums are nice but if I was going to put a trojan in to something, I'd probably rebuild the md5sum too. Basically md5sum is a glorified CRC at the end of the gzip, nothing more and nothing less.

      Do this: Download gpg from gnupg.org. Build it. Generate yourself a key. Try to get some of your friends to sign it. submit it to keyserver.net. Sign your code with that key. While you're at it, start using kmail, evolution, or mozilla with enigmail and start signing your emails too. Do it religiously.

      Check sigs when you download code too.

  • mars.raketti.net (Score:3, Interesting)

    by solostring ( 620535 ) on Wednesday November 13, 2002 @08:35AM (#4658465) Homepage
    The program connects to 212.146.0.34 (mars.raketti.net) on port 1963

    With that information, I suppose that it is easy to find out which Finnish 'author' included the trojan, and would be simple to track him down. But my question is how something like this could have been included in an open source code and released to the general public?

  • This is a growing trend (Score:2, Interesting)

    by Anonymous Coward
    This never used to happen. Now it is like as if someone is intentionally trying their luck to trojan open-source projects. The crack0r types usually try to claim some kind of responsibility to increase their m0j0, but I haven't heard of anyone doing so. Usually a crack0r will try to make the trojaning *bad* to further make themselves feel better, but these trojanings are often in name only, and are of no real security threat. I am wondering if this is an anti-freesoftware publicity ploy by some individual or group.
  • ... or are script kiddies getting better?

    Seriously, though, I think the ideal solution would be to do multiple checks of the RC5 signature of newest packages, over several mirrors. The advisory mentioned that tcpdump.org was compromised, while the mirror at ibiblio.org was OK.

    Or use Gentoo Linux. Of course. I can't do that, since I don't have broadband at home... =(

  • One too many? (Score:4, Insightful)

    by simpleguy ( 5686 ) on Wednesday November 13, 2002 @08:42AM (#4658522) Homepage
    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.

    • Re:One too many? (Score:5, Insightful)

      by LostCluster ( 625375 ) on Wednesday November 13, 2002 @08:55AM (#4658622)
      As Linux becomes more popular, the dumber system admins who never patched their Windows systems now have Linux systems. All it takes is a small handful of people to not know there is a wide-open back door, or worse yet know but be too lazy to take the corrective action, and there's enough zombies to cause headaches.

    • Re:One too many? (Score:3, Informative)

      by ei4anb ( 625481 )
      www.netcraft.com says www.tcpdump.org uses OpenSSL/0.9.5a

      http://www.openssl.org/news/secadv_20020730.txt says that is vulnerable.

      Everyone using OpenSSL 0.9.6d or earlier, or 0.9.7-beta2 or earlier or current development snapshots of 0.9.7 to provide SSL or TLS is vulnerable, whether client or server.
    • Or maybe there is a *VERY NASTY* exploit circulating privately? This is why the people who set up honeynets and dissect the scans are our heroes. They would hopefully detect unknown exploits in software, just by looking at the fingerprint of the attack and figuring out if it is already known.

      That being said, that alone is not enough. Everyone should run their updates nightly, and make sure their security don't collapse completely once one box has been taken.

      However, I would like to take the opportunity to applaud the honeynet people who actively act like sitting ducks in order to protect the rest of us.

  • cleaning? (Score:3)

    by mr. marbles ( 19251 ) on Wednesday November 13, 2002 @08:45AM (#4658545)
    so seeing as how there's no trojan cleaning program in linux, how does a person infected with the trojan rid his system of it? is it as simple as installing the non-trojan version?
  • ...that this little incident will not be mentioned in the next edition of the Cathedral and the Baazar?

  • Reply from a mirror site to HLUG and tcpdump.org (Score:5, Informative)

    by Dogcow ( 7944 ) on Wednesday November 13, 2002 @09:00AM (#4658661)
    This was just sent ~1 min ago:

    To : msolnik@hlug.org
    Cc : wt-changes@wiretapped.net,
    tcpdump-workers@tcpdump.org,
    mcr@sandelman.ottawa.on.ca
    Subject : tcpdump.org mirrors
    ----- Message Text -----
    Hi guys,

    I run the main mirror of tcpdump at wiretapped.net (no relation to wiretapped.us) in Australia. We rsync from cvs.tcpdump.org, and have removed the entire tcpdump.org tree and disabled rsync updates until we hear from Michael Richardson at tcpdump.org.

    You may like to add this info to your Updates area, as the unavailability of the main mirror site may seem suspicious. It is not, as described above.

    Because wiretapped.net itself is mirrored to a few other sites, it may take between 1 hour and 24 hours for this removal (and any subsequent re-addition) to take effect. We'll note when it goes back online at http://www.wiretapped.net/changelog.html

    Hope this assists in preventing any further spread,

    Grant
    www.wiretapped.net

  • Accountability (Score:2, Interesting)

    by Mephie ( 582671 )
    I admit to not knowing a lot about open source development, not being a developer myself. But I'm curious, is there any sort of legal accoutability when someone intentionally codes a trojan in to a piece of software? Is it possible to keep track of who is writing what code? When trojans, etc, are discovered, are you limited to just patching them and going from there, or is it usually possible to find out who did it and therefore be suspect of future code?
  • I thought the whole idea of the GPL was that you could take a program and modify it to your own needs so long as you release the source back to the community under the same license.

    Sounds like that's what happened here!

  • Uncommented trojan (Score:5, Insightful)

    by magi ( 91730 ) on Wednesday November 13, 2002 @09:10AM (#4658733) Homepage Journal
    The trojan code [151.164.128.17] 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.

    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 /* 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.

    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.

  • DEMAND PGP SIGNATURES!!!! (Score:5, Insightful)

    by aphor ( 99965 ) on Wednesday November 13, 2002 @09:18AM (#4658810) Journal

    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!

  • Would it help to have a source Bank? (Score:3, Interesting)

    by cmeans ( 81143 ) <chris...a...means@@@gmail...com> on Wednesday November 13, 2002 @09:52AM (#4659081) Journal
    A single place where OS projects could deposit their code (on whatever frequent basis they liked), that would "guarantee" that the code was free of Trojans etc. before making it available to others for download...

    I'm just typing out loud here.

    Yes, there'd almost certainly have to be a cost associated with this, and I'd think it would be paid by the people who wanted source code, but didn't want to have to worry about checking it for Trojans etc..

    The source could still be publically available for comment and review to add to those being paid to perform the analysis.

    Seems like this might be a good service, once the idea is fleshed out more...

    There'd also need to be some definition of "guaranteed" (or maybe just a different word :0) that fit this scenario, most people don't want to set themselves up to be sued.

  • Sandbox Your Applications (Score:5, Informative)

    by gehirntot ( 133829 ) on Wednesday November 13, 2002 @10:04AM (#4659194)
    Lately, we have seen many trojaned distributions. To prevent these problems from affecting us in the future, we need to use cryptographic signatures as part of software distribution. Otherwise, we never know if a particular piece of software is authentic or not. Signature checking needs to be part of the installation process. I believe that Debian's aptget is one of the few tools that actually does this.

    In the meanwhile, I suggest that you run all your untrusted software in a sandbox like Systrace [umich.edu] which is available for the BSDs and Linux.

    This screenshot [umich.edu] shows Dug Song detecting the trojan in the Fragroute [monkey.org] distribution. Systrace allows you to run completely untrusted applications in a sandbox. The security policy is created on the fly with the user deciding what an application is allowed to do.

    We need to be much more careful about the software that we run.

  • a quick test to see if your hit (Score:4, Informative)

    by Anonymous Coward on Wednesday November 13, 2002 @10:13AM (#4659269)
    login as root (or whoever can run tcpdump)

    tcpdump -n host 212.146.0.34 &
    telnet 212.146.0.34 1963

    if tcpdump sees the connection since it isn't ignoring port 1963, if you don't see the connection, then your tcpdump is ignoring port 1963

    and well, its always nice to /. your local rooted base.
    the people at 212.146.0.34 should change it to something like /usr/bin/tcpd echo 'A' (i think that was the quit code)

    if this test is wrong, well, so be it, i'm still new at this linux thing, but i'm better at linux then i am at spelling (boy, i should be an /. editor)
    --Anonymous Coward

  • Early news from tcpdump.org (Score:5, Informative)

    by fenner ( 625492 ) on Wednesday November 13, 2002 @10:14AM (#4659286) Homepage
    I moved the binaries on the tcpdump.org web site, so that the "download" links won't work.

    "ls -c" says that the modified binaries were installed at Nov 11 10:14:00 2002 GMT.

    Preliminary inspection says that the CVS repository is O.K.

  • www.tcpdump.org (Score:3, Insightful)

    by kludge99 ( 196947 ) on Wednesday November 13, 2002 @10:19AM (#4659347)
    Interesting that there is no mention of this on the tcpdump.org website, one would think they would at least post something about it.

  • Date of Trojan is after Nov 1, 2002 (Score:5, Informative)

    by Skjellifetti ( 561341 ) on Wednesday November 13, 2002 @10:35AM (#4659554) Journal
    I downloaded and installed libpcap and tcpdump on Nov 1. The versions I have came from tcpdump.org. md5sum shows that they have the correct checksum and not the trojaned checksum as reported on the Houston LUG page. A grep of the sources for the port number and ip found in the trojan reports null. It looks like the trojan files were placed on tcpdump.org after Nov 1, 2002.

  • DeMorgan's Law (Score:3, Interesting)

    by srichman ( 231122 ) on Wednesday November 13, 2002 @03:08PM (#4662499)
    I mean, really, who writes code like this!?
    if (!(!buf || !*buf)) {
    We have a tricky tricky trojan writer on our hands. With obfuscation like this, it's a wonder the trojan was found at all...

Slashdot Top Deals

The fancy is indeed no other than a mode of memory emancipated from the order of space and time. -- Samuel Taylor Coleridge

Close