Slashdot Mirror

Actually, CERT gave the announcement on June 10. What you have noticed is that Slashdot has decided to post a story about the announcement on the same day the patch is made available.

<conspiracy> What you should be wondering is if this has anything to do with the fact that Slashdot receives revenue from Microsoft advertising. </conspiracy>

Use a different web browser There are a number of significant vulnerabilities in technologies relating to the IE domain/zone security model, the DHTML object model, MIME type determination, and ActiveX. It is possible to reduce exposure to these vulnerabilities by using a different web browser. Such a decision may, however, reduce the functionality of sites that require IE-specific features such as DHTML, VBScript, and ActiveX. Note that using a different web browser will not remove IE from a Windows system, and other programs may invoke IE, the WebBrowser ActiveX control, or the HTML rendering engine (MSHTML). It is possible for a different browser on a Windows system to invoke IE to handle MHTML protocol URLs.

"There are a number of significant vulnerabilities in technologies relating to the IE domain/zone security model, the DHTML object model, MIME type determination, and ActiveX. It is possible to reduce exposure to these vulnerabilities by using a different web browser, especially when browsing untrusted sites. Such a decision may, however, reduce the functionality of sites that require IE-specific features such as DHTML, VBScript, and ActiveX. Note that using a different web browser will not remove IE from a Windows system, and other programs may invoke IE, the WebBrowser ActiveX control, or the HTML rendering engine (MSHTML)."

It was only mentioned two posts before this that CERT advised people to stay away from IE, even though CERT released that advisory on June 10, and it was even reported on BBC on June 14. Now this story comes along mentioning the patch will be available later today? The CERT advisory could have been published on Slashdot nearly a month ago, but conveniently is published on the same day as the fix is released. Was it intentional to keep information about the CERT announcement off of Slashdot until the fix was released?

What about a link to the Washington Post? The actual recommendation to use another browser was somewhat unrelated to the IIS5 advisory from CERT referred to by the Washington Post.

There's a copy at http://www.kb.cert.org/vuls/id/323070. Right down at the bottom under "Use a different web browser".

Use a different web browser

There are a number of significant vulnerabilities in technologies relating to the IE domain/zone security model, the DHTML object model, MIME type determination, and ActiveX. It is possible to reduce exposure to these vulnerabilities by using a different web browser. Such a decision may, however, reduce the functionality of sites that require IE-specific features such as DHTML, VBScript, and ActiveX. Note that using a different web browser will not remove IE from a Windows system, and other programs may invoke IE, the WebBrowser ActiveX control, or the HTML rendering engine (MSHTML).

The Department of Homeland Security's U.S. Computer Emergency Readiness Team touched off a storm this week when it recommended for security reasons using browsers other than Microsoft's Internet Explorer.

CERT gave the warning on June 10 . BBC reported this on June 14 .

a link (http://www.kb.cert.org/vuls/id/323070) to the US-CERT pub recommendation. It is also interesting to note that the suggestion to "use a different web broswer" is the last offered (see section III. Solution).

CERT gave the warning on July 10. BBC reported this on June 14. I tried to submit 5 different revisions of this story on June 16. I thought it was important to get the word out because I would like to have known about this if I was running windows (I did on my old laptop).

Old News for Nerds. Stuff that mattered.

"In the meantime, we have provided customers with prescriptive guidance to help mitigate these issues."

Ummm... I don't think so.... here is a link to the US-CERT Vulnerability Note VU#713878 which (I think) is where this all starts. Go right to the bottom (OK, this is slashdot, so I'll cut-and-paste)

Use a different web browser

There are a number of significant vulnerabilities in technologies relating to the IE domain/zone security model, the DHTML object model, MIME type determination, and ActiveX. It is possible to reduce exposure to these vulnerabilities by using a different web browser, especially when browsing untrusted sites. Such a decision may, however, reduce the functionality of sites that require IE-specific features such as DHTML, VBScript, and ActiveX. Note that using a different web browser will not remove IE from a Windows system, and other programs may invoke IE, the WebBrowser ActiveX control, or the HTML rendering engine (MSHTML).

The way I read that last sentence, CERT say you are not safe unless you get rid of the IE6 functionality.

You can get info about these problems by searching for "java" at cert.org. The most recent one I found was patched last month.

The Nimda worm was another hybrid, perhaps even nastier. It spread(s) using Outlook Express, IE and IIS, as well as Windows network shares. See the Nimda Cert advisory

you are wrong. check this out. it's a link to a CERT advisory two weeks ago detailing the unpatched IE exploit that was used in this attack.

and I'm pretty sure I saw that recommendation on the blurb alerts CERT puts up on its front, but I don't see it now.

Resolution

Apply a patch

Although a patch is not yet available for this issue, it is a good practice to use Microsoft Windows Update to help ensure the security of your computer.
Disable Active scripting and ActiveX controls

Instructions for disabling Active scripting and ActiveX controls in the Internet Zone can be found in the Malicious Web Scripts FAQ.
Do not follow unsolicited links

Do not click on unsolicited URLs received in email, instant messages, web forums, or internet relay chat (IRC) channels.
Run and maintain an antivirus product

It is important that you use antivirus software and keep it up to date. Most antivirus software vendors frequently release updated information, tools, or virus databases to help detect and recover from virus infections. Many antivirus packages support automatic updates of virus definitions. US-CERT recommends using these automatic updates when possible.

US-CERT is aware of new activity affecting compromised web sites running Microsoft's Internet Information Server (IIS) 5 and possibly end-user systems that visit these sites. Compromised sites are appending JavaScript to the bottom of web pages. When executed, this JavaScript attempts to access a file hosted on another server. This file may contain malicious code that can affect the end-user's system. US-CERT is investigating the origin of the IIS 5 compromises and the impact of the code that is downloaded to end-user systems.

Web server administrators running IIS 5 should verify that there is no unusual JavaScript appended to the bottom of pages delivered by their web server.

This activity is another example of why end users must exercise caution when JavaScript is enabled in their web browser. Disabling JavaScript will prevent this activity from affecting an end-user's system, but may also degrade the appearance and functionality of some web sites that rely upon JavaScript. US-CERT recommends that end-users disable JavaScript unless it is absolutely necessary. Users should be aware that any web site, even those that may be trusted by the user, may be affected by this activity and thus contain potentially malicious code.

we recommend that you (*) install and maintain anti virus software (*) if possible turn off javascript, or use a browser other then MSIE until the current vulnerabilities in MSIE are patched.

CERT have suggested using a different browser before (e.g. here).

I wouldn't read too much into it myself though. If one browser has a vulnerability, and another doesn't, surely it's an obvious thing to suggest? And in the past, they've pointed out the potential problems with not using IE (i.e. incompatibilities with IE-dependent sites). More a suggestion than a recommendation I'd say.

Another good rootkit checker, which seems to have a more active development cycle, is Rootkit Hunter. Here's a Newsforge article on it, with a few more details.

A few other comments:

Virus scanners won't help on jot against a custom hack (as Valve found out, for instance). They can be helpful, but don't put full reliance on them.

Running an Intrustion Detection/Prevention System such as Snort, Samhain, Prelude, etc. will help you manage the monitoring side of things; more than a few machines becomes a pain without additional help. Also take a look centralising all your logs on a syslogng server or something similar, if you don't already (note that there are various solutions out there to get Windows boxes to log to a syslog server).

A honeypot may distract the hacker from your production servers for long enough for you to identify that there's a problem.

Also take a look at "HoneyTokens": specifically created database records that trigger alarms if they're accessed - usually high profile fictious targets that would make excellent trophy hacks - there's more info on this over at SecurityFocus.

If you suspect that a machine has been compromised, as other have said, the ONLY WAY TO BE SURE is to rebuild the box from scratch. While this may be a real pain, hopefully it'll help you get the procedures in place to make this as painless as possible, so it's not all bad.

Perform security audits/pentests every now and again. Tools like Nessus help: here's a good series on using Nessus (part 2, part 3).

Get familiar with security tools such as the top 75 recommendations at Insecure.org (home of Nmap).

Remember that security is a PROCESS, so be thorough; get an entire plan together and cover all the bases that you can, taking special care to identify and cover the weak points. Your company's security is only as good as its weakest link; for instance, priviledge escalation of weak user account passwords is a good one.

Read SecurityFocus, PacketStorm, CERT and the like, and try to get involved in their communities; they can be invaluable! They're also got a lot of good tutorials, such as how to lock down Apache, IIS; securing PHP, ASP; etc.

Cert/CC has an article called "Before You Connect a New Computer to the Internet"

I'm sorry... javascript is a requirement on the modern web.

What makes you say that? Many websites use Javascript, very few rely on it. The majority of Javascript in use on the web is either rollovers or form validation, neither of which are essential (more relevent: neither of which are more important than security).

In fact, CERT advise users to switch off client-side scripting.

It's interesting you point out that "Even the devil can cite scripture for his purpose", and then proceed to assume it's only fair to include vulnerabilities of one of the most exploited scripting environments in order to inflate the Apache vulnerability count. Completely ignoring the fact that vanilla Apache has fewer vulnerabilities than IIS.

If you insist on including a scripting module, why didn't you choose the popular mod_perl?
Oh, whoops, that's not nearly as close!

Funny how that works. ;)

And in turn, CERT's vulnerability count for apache can demonstrate this statement is simply false.

And to qoute Shakespeare, "Even the devil can cite scripture for his purpose": if you want to fairly compare this to IIS's problem count, you should include an application scripting environment, as IIS includes ASP. Let's say PHP, since it seems to be the most popular; we get this count.

Quite close, aren't they?

- Oisin

And in turn, CERT's vulnerability count for apache can demonstrate this statement is simply false.

And to qoute Shakespeare, "Even the devil can cite scripture for his purpose": if you want to fairly compare this to IIS's problem count, you should include an application scripting environment, as IIS includes ASP. Let's say PHP, since it seems to be the most popular; we get this count.

Quite close, aren't they?

- Oisin

And in turn, CERT's vulnerability count for apache can demonstrate this statement is simply false.

And to qoute Shakespeare, "Even the devil can cite scripture for his purpose": if you want to fairly compare this to IIS's problem count, you should include an application scripting environment, as IIS includes ASP. Let's say PHP, since it seems to be the most popular; we get this count.

Quite close, aren't they?

- Oisin

The Sasser worm has recently disabled the computer systems of Britain's Coastguard. Naturally, this event raises even more doubts over the reliability of Microsoft software in critical systems.

Naturally this event *doesn`t* raise doubts about running unpatched systems that arent even protected by packet filters (which, for al their faults would have prevented this) and connected to way to many other computers (Not limited to but, usually meaning the Internet) and listening on to many ports/interfaces with to much code at to high privileges anywhere (let alone in critical systems).

Naturally...

No sir, this is just a microsoft problem. This isn`t another case of RPC gone a little to easily accesable. This has nothing to do with RCP api`s being undocumented (security through obscurity). This isn`t another example of just running the whole piece of networking code with as much privileges as we can come up with and keeping dumping functionality in. It is just naturally microsofts fault. No I am not saying it isn`t microsofts fault, it is, naturally. They could have learned that coding rpc services in a buffer overflow prone way without tripple checking buffers isn`t all that smart. And they could have learned this years ago. But they didn`t, they went the "natural"/go with the flow way about this. Lazy. I mean everybody does RPC services in C with every privilege out there without caring for bugs enough. And they never released documentation for these network related api`s so, lets just keep doing it like that, its the natural order of things.

The software industry needs some natural selection on this..... this goes for all operating systems, naturally.

How about where /bin/login doesn't bind to a port and listen to inbound traffic 24/7/365?

Yes, there was a hole /bin/login too, but if you're running a desktop that you don't expect to log into from anything other than the console, you can turn off crap like telnetd.

Because I don't. I use Macintosh. However, I see the advantages of Windows, *nix, Mac, etc. Each has their own place. Take a look at the Linux notes on CERT (Just in one month alone, if you wish).

The heap overflow vulnerability mentioned here only applies to the Windows version of the Quicktime player, not the Mac OS version.

See here (section IV), or here, or here.

"It was wholly dependent upon openssl. 9.2.1 is two years ago."

That is patently untrue bullshit, but you continue to lie about it. Perhaps you'd like to take a look at the CERT advisory if you still think I'm mistaken. Quit giving the OpenSSL guys all the blame.

Of course, this does not mean recent version of BIND are less secure than tinydns. They may even be more secure. But give ISC's track record, I'll stick with tinydns, written by an author that still holds an ounce of credibility regarding security issues in his products. You can deal with your downtime, lost productivity, and unhappy customers when you get hacked, DoSed, or just have to recompile BIND yet again.

Oh, and half those features you mentioned are unnecessary for 80% of sysadmins out there or you're just being unclear about what you mean. And that's pretty funny, telling ME to drop the attitude, since I only suggested a more secure DNS server for the general populus and you flew off the handle.

And it's unclear why the DNS management services you mention need to be included in the DNS server software. This is UNIX we're talking about, right? Since when did UNIX advocate one tool for many jobs? But that's precisely what BIND is.

Your attitude is what bothers me more than BIND, though. I hope you don't manage systems for a living, because I'd hate to be your boss. Your religious zealotry only serves to hurt your case, and you don't seem to be open to alternatives to the products you use. It smacks of unprofessionalism. You make blind assertions, blatently lie in several posts about the flaws of BIND, and exaggerate the usefulness of poorly designed and questionably standardized "features." I can only assume that you work for ISC or make money selling support for BIND, since you clearly want others to avoid even trying tinydns or evaluating it as an option. Good day.

Thing is, if the person who sent it to you *does* know about computers, they will know you are a tool.

Try and convince me that there have _never_ been exploits via html & pdf.

Here's the latest PDF one.

Did you know that Melissa and Goga were originally delivered via RTF ?

Here is a list of some things that I feel are worth considering:

1. Patch your system! As soon as a patch comes out, get it applied and reboot if you have to! Also, stay up to date on security issues by subscribing to mailing lists that are related to the software your using. One good general purpose site is cert.org. Keep in mind that while mailing lists are great ways of being notified, they arent fool proof. If your subscription expires and you dont know about it, you wont be exactly up to date in the community now will you?

2. Use grsecurity. This is a kernel patch that is briefly lagged behind official Linux kernel versions. It has many great features for protecting against stack attacks/buffer overflows. ie: Those latest greatest scripts your local script kiddie just downloaded wont likely do anything against you since special addresses are randomised. It can also hide files on your computer such as intergrity checkers so nobody except you know they exist. Plus it can stop insert code into a running kernel by making kernel memory readonly (which btw, would have prevented at least one of the attacks they mentioned).

3. Install a filesystem intergrity checker. Aide, integrit and tripwire all come to mind and essentially all do the same thing but with different config file syntax. Besides, how can you tell if a file is changed if you dont actually check? Also, dont forget to hide the existence of this program using something like grsec's gradm filesystem ACL util and be careful of automating checks in the crontab!

4. Read a good linux securing article. One such article I have read is called Securing & Optimizing Linux: The Ultimate Solution. It will teach you how to lock a system down a fair bit and how to remove unused/unneeded services from your computer.

5. Watch those logs! Log files provide a wealth of information, but administrators rarely check them (well, not all). If you dont know what a log entry means, research it, or else you may be looking at an attack and not even realise it. Now I know some of you are thinking I am nuts considering just how many logs even a small system generates, but there are tools to help you. One way is to use a program called swatch (a perl script). It can parse existing and old archived log files using a perl regex syntax and trigger actions based on found text. Start by configuring the system to ignore any log entries that are known to be friendly and show you everything. Then slowly eliminate each friendly entry one at a time. What will be left is a list of purely evil enteries :). Next configure swatch to alert you upon recieving such messages! Of course you can always use perl or even grep -v to parse logs, but for repeated use I think a specialised tool would save you some trouble in the long run.

Now I know I could go on forever with suggestions, but I think that these few things should give anyone a kick in the right direction. I hope this has been helpful.

For those of you wondering about OCTAVE: it is the Operationally Critical Threat, Asset, and Vulnerability Evaluation. (It's not really about survivability as such.)

Please understand that what follows is my opinion only.

OCTAVE is interesting: it involves getting input from all levels of the organization to determine what is important to whom and why. This is a pretty effective way to figure out a) what would happen/be affected if $RESOURCE became unavailable, and b) how to best protect $RESOURCE. Having said that, OCTAVE is probably a bit too time-consuming for most organizations; many companies, for example, may not be able to dedicate all the requisite personnel - most of them mission-critical - to a potentially months-long OCTAVE cycle.

I wouldn't say it is outdated; on the contrary, it is conceptual (vice purely operational) and as such ages better than most technical FAQs and HOWTOs.

There is a version for small[er] businesses - i.e. fewer than 100 people - called OCTAVE-S (colloquially called OCTAVE Lite). You can read about it here (scroll down a bit).

Cheers!

For those of you wondering about OCTAVE: it is the Operationally Critical Threat, Asset, and Vulnerability Evaluation. (It's not really about survivability as such.)

Please understand that what follows is my opinion only.

OCTAVE is interesting: it involves getting input from all levels of the organization to determine what is important to whom and why. This is a pretty effective way to figure out a) what would happen/be affected if $RESOURCE became unavailable, and b) how to best protect $RESOURCE. Having said that, OCTAVE is probably a bit too time-consuming for most organizations; many companies, for example, may not be able to dedicate all the requisite personnel - most of them mission-critical - to a potentially months-long OCTAVE cycle.

I wouldn't say it is outdated; on the contrary, it is conceptual (vice purely operational) and as such ages better than most technical FAQs and HOWTOs.

There is a version for small[er] businesses - i.e. fewer than 100 people - called OCTAVE-S (colloquially called OCTAVE Lite). You can read about it here (scroll down a bit).

Cheers!

This paper addresses some of the issues you mentioned.

ObDisclaimer: I am one of the authors (though no longer at CERT) and express some opinions in the paper re: patching schedules and general due care in this area.

I've always considered this to be CERT, not this.

Apparently our new Dept. of Homeland Security launched us-cert.gov as a partnership with Carnegie Mellon's cert.org (and others, in the future).

I feel safer already.

Unless the said virus/worm/compromise is using a remotely
exploitable buffer overlow or locally explotable programming
errors in say: apache , OpenSSL , or sudo
some times is even trivial for the attacker to
take over ....

We looked at dozens of OSI licenses and failed to find one which met all of the requirements. The fork-ability and lack of credit requirements are biting many OSS security projects in the ass right now...

If you don't want to open source the database, that's your prerogative. But you should not have called your project the Open Source Vulnerability Database! That's my whole point.

Nessus is GPL, so I don't see how anyone could be "ripping off the code", considering the code is free and much of it is written by unpaid volunteers in the first place. Furthermore, Renaud does make a lot of money by licensing those volunteers' efforts to commercial outfits, so who exactly is getting ripped off? If people are rebranding Nessus without crediting Nessus, that violates the GPL. The BSD license also contains a credit-due clause. It's not fair to blame the license if nobody enforces it.

Unfortunately, your objections to open source licensing models don't ring true. Here's what I suspect is going to happen. The OSVDB project is going to brand itself as a "community" and "open source" effort, harness the hard work of hundreds of volunteers, and then it's going to get "bought" by Digital Defense in a year or two, and they are going to start trying to squeeze revenue from it. Look what happened to Bugtraq after it was bought by SecurityFocus (and then later by Symantec). Why else would the company be bankrolling it? Out of the goodness of their hearts? Hell, even CERT started charging for advanced vulnerability notification last year.

You could go a long way towards dispelling these concerns (which have been voiced by others in other forums) by actually making the project open source (GPL, GFDL, or BSD), instead of just using the phrase "open source" as a marketing term.

These two organizations are not the same thing. I'd trust the DHS about as much as I'd trust Goebels.

'Never once been' is ambiguously phrased, believe you mean your systems have never been cracked. Congrats. Ours either. You are correct, keep up with patches, monitor (eg aide), so far zero problems. Wish everyone did. Got loaned to team in another wing to help them recover when they were cracked via snmp and again when they didn't bother to patch a new box for sadmind. Some people refuse to learn.

'Never once been' is ambiguously phrased, believe you mean your systems have never been cracked. Congrats. Ours either. You are correct, keep up with patches, monitor (eg aide), so far zero problems. Wish everyone did. Got loaned to team in another wing to help them recover when they were cracked via snmp and again when they didn't bother to patch a new box for sadmind. Some people refuse to learn.

Odd couple?

I don't think they're that different. Sounds like a match made in security hell.

Soko

Odd couple?

I don't think they're that different. Sounds like a match made in security hell.

Soko

Odd couple?

I don't think they're that different. Sounds like a match made in security hell.

Soko

Odd couple?

I don't think they're that different. Sounds like a match made in security hell.

Soko

What are you talking about? Linux has never suffered a buffer overflow.

"Irrelavent. One of the often cited benefits of Linux is that the source code is easily accessible thus leading to secure code."

Bad reading comprehension. This is not irrelevant. My point was addressing the comparison between Windows and Linux "being the same" with the regard to "serious bugs", which they most certainly are not. Your claim about the "shallow bugs" argument going out the window is also bunk, see my point about exploit complexity.

---
"There's no difference between the two. Exploits on Windows have had carefully crafted buffer overflows."

This is merely a matter of paying attention. Certainly both operating systems have had very intricate security holes, but Linux bugs tend to be, as a matter of history, more complex when compared to those on Windows. As an example comparison to see what I'm getting at:
IIS vulnerability from GET request buffer overflow and Synopsis: Linux kernel do_mremap local privilege escalation vulnerability.

---
"I would have to say that Microsoft does a fairly good job [alerting everyone when a bug is found]."

This is naive at best, flat out ignorant on the other end. Security companies from all over have submitted bug report following bug report to Microsoft which go without acknowledgement. Undisclosed bug fixes are quietly rolled into patches designed to fix something else entirely. Many fixes in Serivce Packs either haven't been announced before or are thrown in the SP without mention.

I won't bother going into any more detail. At best, you need to do your homework, at worst, you need to stop trolling.

Cheers

> Windows users are less likely to run a webserver,
> simply because they're not as eager to play with
> their system as Linux users. Therefore there
> will be less insecure Windows servers. The same
> goes for Mac-OS users.


The study was talking about servers. So your comment about Windows users being less likely to run a webserver makes no sense whatsoever. In terms of the study, they are every bit as likely to be running a webserver.

Linux users have to face the facts when addressing this matter and not bury their heads in the sand. There are any number of Linux users who don't even know what inetd and tcpwrappers are let alone bugtraq and cert or how to upgrade their systems and keep them secure or how to write PHP scripts with bounds checking.

Until that changes Linux boxes are going to continue to be broken into wholesale.

The reaction to this story on here reminds me of when Apache and IIS were put head to head in some study and there was wholesale denial that IIS could outperform Apache. The Apache team recognised there was a problem though and set about improving their software. This is what Linux users have to do now.

Whilst the study may be flawed and the company that did it may have an agenda, 13000+ Linux break-ins in a year should be serious cause for concern.

Folks, please face the facts even if they are unpleasant and improve the software and more importantly improve the education of the user base.

Hi Russel, nice article. Can I ask you though why didn't you mention the other side of the equation - well hidden back doors in such proprietary software as Borland/Inprise Interbase 4.x and 5.x ?

If we look at this site we will see that while Interbase code was closed at Borland, the back door was not found and could only be revealed once the source became open in the Open source Interbase 6.0 and 6.01

You will also see an example of an Open source Firebird 0.9-3 and earlier having a back door account. Now let's see, in both cases the back doors were found in the Open Source Software, however in the first case the reason the back door was found was exactly because the code was released as open source. What does this tell us? There must be more occurrences of hidden back doors in proprietary software than in the open source software because in the open source software these things don't stay hidden for too long. To answer your question " Because anyone can create and market--or give away--a Linux distribution, there's also a reasonably high risk that someone will create a distribution specifically intended to subvert security. And how would anyone know?" - this is how they will know, by compiling a binary from a trusted brunch of the code and comparing the binaries. That is one way to know. On the other hand code under GPL must be also distributed as source code. So simply get the source from your vendor and check it by either compiling it and comparing binaries or hiring an outside consultant to go over the source.

You cannot easily go over the source of a proprietary system, which makes a job of security certification so much harder. You see, your article is very one-sided, could you please make some amendments to it and include the discussion of the dangers of the proprietary code, and include some examples, since facts make an article so much more believable, more than just simple fud.

Thank you.

The attempts failed because of the meticulous grooming given by the "many eyes" watching each open source release.

Any one can write a new kernel patch. But getting these patches accepted is a whole different story.

Conversely, years after the commercial, closed-source program Borland Interbase was released and used worldwide, it was found that it contained a back-door.

So recent history proves the article is wrong. Facts demonstrate exactly the opposite of what the article rants about.

Conclusion: the article is an unsubstantiated troll written by a Microsoftie eager to fart FUD at the Penguin. Ignore.

II. Impact

The potential exists for an intruder to have inserted back doors, Trojan horses, or other malicious code into the source code distributions of software housed on the compromised system.

III. Solution

We encourage sites using the GNU software obtained from the compromised system to verify the integrity of their distribution.

Sites that mirror the source code are encouraged to verify the integrity of their sources. We also encourage users to inspect any and all other software that may have been downloaded from the compromised site. Note that it is not always sufficient to rely on the timestamps or file sizes when trying to determine whether or not a copy of the file has been modified.

Background

When downloading software from online repositories, it is important to consider the possibility that the site has been compromised. One of the threats that users face is that intruders could include malicious code in the software packages distributed by those sites. This code could take the form of Trojan horse programs or backdoors.

Take a look at cpan and some of the modules you have on your machine. How many are updated with normalcy? What about the whole sourceforge/freshmeat concept of 'sysadmining', where you find a neat program supported for what... a year? Maybe 2 if you're lucky...

Sometimes it seems the cool Open Source gets, the more issues come out with it.