Slashdot Mirror

I wrote it years ago, but it's still quite relevant:
http://www.cert.org/blogs/certcc/2009/06/vulnerabilities_and_software_a.html

Coding quality and exploit mitigations aside, there's something to be said for the size of the software that you're installing. The more code that's there, the more there is to attack. If you're using Reader, you might ask, why is there a 3D rendering engine in my PDF reader? Or maybe even do something about it.

This is supposed to be reassuring? How many people will ever read about this? And how long until it's turned on by default? Or perhaps turned on by a remote message.

On the latest version of iOS, on the welcome screen on first boot it explicitly asks you if you want to turn on the sending of diagnostics and stuff like location services. This was Apple's response to the privacy kerfuffle after the location tracking thing. Yes I am disappointed it's even in there but Apple is doing the right thing here by disabling it by default.

I've found it useful as an example for people who don't understand why we need free/open software. This story simply means that if you use your phone to access anything that is protected by a password (or PIN or whatever), that little hidden bit of software is making a copy of your login, password, account numbers, etc., and sending it off to some site that you know nothing about. Whoever has that information can then get into your account and do as they like with it. I've seen a lot of worried looks, and I know a number of people who have held off on the idea of using their phone to access their bank accounts as a result of this information.

CERT Advisory CA-2002-24 Trojan Horse OpenSSH Distribution

Don't we already have one?

The nerdily-named Computer Emergency Response Team
http://www.cert.org/

Why do I imagine post-doc geeks wearing black sitting around in a darkened room in a "situation room" with huge screens looking at live monitoring logs?

And also asking each other, "Doctor, do you concur?"

Not sure, but Evince shares the Poppler library backend with Okular, which uses FreeType 2 internally, which was susceptible to the iOS JailbreakMe attack. Okular crashed to one of these hijacked PDFs, likely because the payload targeted iOS and not Linux. Beware the PDFs :).

And that you are verifying the MD5 checksum of the source code to the build on my phone! And a UN panel to supervise the foundry in which the hardware md5 check was being performed!

nah, not enough. md5 is COMPLETELY BROKEN!!!11!

Sorry, I meant this year (2011). And I linked to the second page of the list instead of the first one. Here is the link to the start page. Rule number one: don't post without sleep :)

Adobe: 5, Microsoft: 4, Cisco: 2, Oracle: 2, IBM: 1, all out of 58. Now, if you take into consideration the number of products Microsoft ships and its installed user base it is a hell lot better than it used to be (remember the days when a new root exploit for IIS came out every week?)

Also, please understand I'm not saying Microsoft is good at security. I'm just saying they're much better than what they used to be. Of course you can argue that -Inf + x = -Inf, for any x :) but that's a totally different issue.

Actually, Microsoft is suffering from bad fame more than anything else. Looking at the CERT database you can see 4 vulnerabilities in MS products in the middle of tons of others. They effectively have taken security somewhat seriously (it did that a long time but that is another story).

On the other hand, Adobe seems to be doing a nice work making sure Flash goes down the drain!

I said this wasn't over a few years after Verisign signed the fake Microsoft cert in 2001. http://www.cert.org/advisories/CA-2001-04.html

I can't find my /. comment on it right now, as it was years ago, but everybody who responded said many checks had been put in place so that type of thing couldn't happen again.

Well, I told you so. The problem is, it only takes one legitimate CA to screw up, and it subverts the entire system for all CAs.

From: CERT Bulletin
Date: 26 Jun 1996 15:43:18 GMT
Subject: CERT Advisory CA-96.13 - Alien/OS Vulnerability
Organization: CERT(sm) Coordination Center - +1 412-268-7090
Approved: cert-advisory@cert.org
Reply-To: cert-advisory-request@cert.org
Keywords: security CERT
Originator: cert-advisory@cert.org

CERT(sm) Advisory CA-96.13
July 4, 1996

Topic: ID4 virus, Alien/OS Vulnerability

The CERT Coordination Center has received reports of weaknesses in Alien/OS that can allow species with primitive information sciences technology to initiate denial-of-service attacks against MotherShip(tm) hosts. One report of exploitation of this bug has been received.

When attempting takeover of planets inhabited by such races, a trojan horse attack is possible that permits local access to the MotherShip host, enabling the implantation of executable code with full root access to mission-critical security features of the operating system.

The vulnerability exists in versions of EvilAliens' Alien/OS 34762.12.1 or later, and all versions of Microsoft's Windows/95. CERT advises against initiating further planet takeover actions until patches are available from these vendors. If planet takeover is absolutely necessary, CERT advises that affected sites apply the workarounds as specified below.

As we receive additional information relating to this advisory, we will place it in

ftp://info.cert.org/pub/cert_advisories/CA-96.13.README

We encourage you to check our README files regularly for updates on advisories that relate to your site.

1. Description

Alien/OS contains a security vulnerability, which strangely enough can be exploited by a primitive race running Windows/95. Although Alien/OS has been extensively field tested over millions of years by EvilAliens, Inc., the bug was only recently discovered during a routine invasion of a backwater planet. EvilAliens notes that the operating system had never before been tested against a race with "such a kick-ass president."

The vulnerability allows the insertion of executable code with root access to key security features of the operating system. In particular, such code can disable the NiftyGreenShield (tm) subsystem, allowing child processes to be terminated by unauthorized users.

Additionally, Alien/OS networking protocols can provide a low-bandwidth covert timing channel to a determined attacker.

2. Impact

Non-privileged primitive users can cause the total destruction of your entire invasion fleet and gain unauthorized access to files.

3. Solution

EvilAliens has supplied a workaround and a patch, as follows:

1. Workaround

To prevent unauthorized insertion of executables, install a firewall to selectively vaporize incoming packets that do not contain valid aliens. Also, disable the "Java" option in Netscape.

To eliminate the covert timing channel, remove untrusted hosts from routing tables. As tempting as it is, do not use target species' own satellites against them.

2. Patch

As root, install the "evil" package from the distribution tape.

(Optionally) save a copy of the existing /usr/bin/sendmai

Oh yes, because iPhone has never ever once had a vulnerability.

You need to be aware of what versions of daemons (like SSH, HTTP, FTP, SAMBA, etc. etc.) are running on your system currently.

You then sign up to security alerts, from your OS vendor, but preferably from somewhere like CERT who will report the vulnerabilities first. If a security vulnerability is reported on something you are running, then ideally you'd turn it off until it's fixed by the OS vendor; if you can't, then wrap some connectivity restrictions around it from a firewall, TCP wrappers or network ACLs to restrict what IP addresses can connect to it. Then patch it when the OS vendor releases an update.

Anyone who cares about security should do this - just because you run Apple doesn't make you special.

http://www.kb.cert.org/vuls/id/559980
Severity metric: 4.50 (on a scale from 0 to 180)

Sounds like not very high to me either, lol.

That said, it's a kinda serious vulnerability given that the Internet relies a lot on DNS and many servers are running BIND.

Then again, we should be running at least DNSSEC by now, and not provided by BIND, right? right?!

That's true, but the CERT advisory only lists the severity metric as 4.5. That's not out of 10. It's out of 180.
http://www.kb.cert.org/vuls/id/559980

ISC very well may use a different ranking scheme for vulnerabilities. DNS is required to have high availability, and this would severely impact that. ISC may rate it highly simply because the common usage scenarios for BIND make this more concerning.

That's because the latest BIND was released specifically to patch this vulnerability. They just didn't really tell anybody about the vulnerability until after 9.7.3 was released. Don't believe me?

CERT was notified at the end of January.
"Date Notified: 2011-01-24" [ http://www.kb.cert.org/vuls/id/559980 ]

The CVE was reserved in the middle of January.
"Assigned (20110111)" [ http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0414 ]

Yet the release notes for 9.7.3 don't mention any fixes which would coincide with this vulnerability:
http://ftp.isc.org/isc/bind9/9.7.3/RELEASE-NOTES-BIND-9.7.3.html

Thanks, ISC, for patching a vulnerability a month after you found out about it and then telling us two weeks later that you did that. That's awesome security procedure there.

Why should I bother disabling it?

Generally, good administrators tend to disable service that aren't wanted or needed in their systems. Who's to say that there's not going to be a vulnerability for the service discovered down the road (*coughSolariscough*) that would make you vulnerable?

Verisign is one of the few CAs that _has_ given out bad certs.
http://www.cert.org/advisories/CA-2001-04.html
http://www.microsoft.com/technet/security/bulletin/ms01-017.mspx

But it doesn't matter. It only takes one CA in your browser/OS's huge list of CAs to sign a cert that's used to MITM you.

None of the popular browsers will give you a warning if the CA changes. For example if you went to China and went to your bank, if CNNIC (one of China's CAs) signs a cert that claims to be your bank, and used that to re-sign your intercepted HTTPS connections, your browser will not warn you. Your traffic would be visible to them without any warnings.

Unless of course you use something like the certificate patrol plug-in.

Windows Explorer once had a bug which could execute arbitrary code via JPEG preview.

Of course, most Linux and BSD systems had vulnerabilites just as bad, where a simple view or preview would trigger an exploit.

Vulneabilities with PNG, gzip, TIFF, PDF, and many others. This happens when everything from your browser to the desktop manager's icon system uses the same vulnerable libary. OSX and Linux systems are simply a more obscure target, and not somehow immune from file parsing vulnerabilities. And before you go off on a "but the user isn't running as root" rant, recognize that Microsoft locked down user privileges by default starting with Windows NT version 4 in 1996. But only, of course, when those windows machines were part of a Windows domain...

Windows Explorer once had a bug which could execute arbitrary code via JPEG preview.

Of course, most Linux and BSD systems had vulnerabilites just as bad, where a simple view or preview would trigger an exploit.

Vulneabilities with PNG, gzip, TIFF, PDF, and many others. This happens when everything from your browser to the desktop manager's icon system uses the same vulnerable libary. OSX and Linux systems are simply a more obscure target, and not somehow immune from file parsing vulnerabilities. And before you go off on a "but the user isn't running as root" rant, recognize that Microsoft locked down user privileges by default starting with Windows NT version 4 in 1996. But only, of course, when those windows machines were part of a Windows domain...

Windows Explorer once had a bug which could execute arbitrary code via JPEG preview.

Of course, most Linux and BSD systems had vulnerabilites just as bad, where a simple view or preview would trigger an exploit.

Vulneabilities with PNG, gzip, TIFF, PDF, and many others. This happens when everything from your browser to the desktop manager's icon system uses the same vulnerable libary. OSX and Linux systems are simply a more obscure target, and not somehow immune from file parsing vulnerabilities. And before you go off on a "but the user isn't running as root" rant, recognize that Microsoft locked down user privileges by default starting with Windows NT version 4 in 1996. But only, of course, when those windows machines were part of a Windows domain...

Windows Explorer once had a bug which could execute arbitrary code via JPEG preview.

Of course, most Linux and BSD systems had vulnerabilites just as bad, where a simple view or preview would trigger an exploit.

Vulneabilities with PNG, gzip, TIFF, PDF, and many others. This happens when everything from your browser to the desktop manager's icon system uses the same vulnerable libary. OSX and Linux systems are simply a more obscure target, and not somehow immune from file parsing vulnerabilities. And before you go off on a "but the user isn't running as root" rant, recognize that Microsoft locked down user privileges by default starting with Windows NT version 4 in 1996. But only, of course, when those windows machines were part of a Windows domain...

And this isn't just applicable to Windows software; FOSS has its share as well: http://www.kb.cert.org/vuls/id/643140

For that matter, any platform that accesses code and data from the same memory (i.e. Von Neumann Architecture) is susceptible to this, as is typical of all general purpose OSes.

It's been known for a while (among those in the security field at least) that signed Java applets have been a concern. A little more info:

http://www.cert.org/blogs/vuls/2008/06/signed_java_security_worse_tha.html

[ ] Implement crypt-md5 support (like /etc/shadow, strong and LDAP-compatible) hashes, or possibly crypt-sha2

Holy shit, they're actually seriously considering MD5. This is embarrassing.

Guys, there's a reason for why I'm saying that MD5 is a Very Bad Idea.

That's straight MD5. Password hashes, using PHK@FreeBSD's algorithm, is a bit more complicated (e.g., a thousand iterations with a salt):

http://en.wikipedia.org/wiki/Crypt_(Unix)#MD5-based_scheme

Most Linux distributions still use the MD5-based hash for their shadow files. Of course using a new algorithm is probably better, but we're (hopefully) not talking about straight MD5, but rather the crypt/PHK variant.

[ ] Implement crypt-md5 support (like /etc/shadow, strong and LDAP-compatible) hashes, or possibly crypt-sha2

Holy shit, they're actually seriously considering MD5. This is embarrassing.

Guys, there's a reason for why I'm saying that MD5 is a Very Bad Idea.

Sorry, but every certificate authority is manually distributed at some point, the verizon's of this planet included, they just have the convenience that browser manufacturers do that for them.

And there's the big difference.

The most automatic way to do what the main requester wants is to set up that certificate authority and roll out your browsers automatically after adding that certificate authority it's root to that browser.

No, the way to do what the main requester wants is to get a free cert whose CA is recognized by most popular browsers. You can get some from: http://www.startssl.com/
Their "product" comparison: http://www.startssl.com/?app=40

You might be able to get free certs from elsewhere.

Apparently some sites sell rapidssl wildcard certs for cheap. I can't remember which ones. Can't find them via Rapidssl's own website for some reason ;).

You have to understand the truth of the matter. Most people dealing with https don't really care that much about security. All they want is not to have those scary browser warnings.

If they really cared about security they would realize that most popular browsers by default do not warn you if a site's CA has changed, or a server cert has changed rather prematurely (I use certificate patrol for that). And that as long as this remains true, all the talk about https security is just talk.

So people should just solve the submitters problem, and implying he's incompetent or even calling him incompetent. Because how many of you are relying on https to keep stuff safe and have CA certs in your browser from CA's you do not trust?

FWIW how many of you really trust Verisign? Stick your hand up if you're that incompetent ( http://en.wikipedia.org/wiki/Verisign#Controversies ). Guess who signs zillions of certs though, and what happens if you don't tell the browser to trust Verisign's certs. Guess who signed a fake Microsoft's cert? http://www.cert.org/advisories/CA-2001-04.html

So just accept that those certs are mainly to make people feel safe and make the browser warnings go away.

IOW, if you go here you'll get what they have.

Not their code. Just their style.

I've tested the latest 10.2 preview of Flash and it is vulnerable. The US-CERT vulnerability note has been updated to reflect this: http://www.kb.cert.org/vuls/id/298081

I used to monitor an independent organization that kept track.
Note that in the beginning there, all the exploits were either *nix or VMS-based, and that was because back then the internet was mostly *nix and VMS. It was only with the advent of PPP that brought millions of Windows machines directly to the internet that Windows became a target.

Even when CERT went down in 2003, there were still plenty of new exploits for *nix systems.. The standard sendmail was a notorious problem for more than a decade, with the same problems re-appearing again and again.

Its as if you guys think that people werent hacking networks before the WWW. Hell, my entire teenage years were before this WWW shit and I always managed to be on the internet by illegitimate means. Back then things were far more wide-open than they are now with "insecure as hell windows" .. you guys have no idea what insecure means. With a good exploit you didn't just own system after system.. you owned network after network.

Ahem... keep in mind, the jailbreakme.com PDF exploit stems from FreeType.

http://www.kb.cert.org/vuls/id/275247

Blaming Apple for an exploit in FOSS code they probably didn't write, is a little unfair, yeah?

Afterall, Red Hat was kind enough to at least credit Apple with the fix in their software update:
https://rhn.redhat.com/errata/RHSA-2010-0607.html

The iPhone "jailbreak" was actually a FreeType exploit delivered in a PDF container. By reports it affected Debian, Gentoo, SUSE, and probably every other platform that supported FreeType. This meant that Linux PDF renderers, like Okular, were crashed by the exploit.

The difference with Linux and Windows is that (AFAIK) Adobe would be crucified if they installed Reader into Firefox, for example. On Windows, Adobe gets away with it no questions asked.

The JailbreakMe PDF/FreeType exploit affected much more than just iOS... potentially every platform in fact. Even Okular was reported crashed by it. Equal blame goes around here for Apple's poor browser plugin handling and insecure FreeType implementation, and Adobe's shitty PDF specification that allows embedded fonts to be stored in documents.

It's stupid that any platform is susceptible to these attacks, when the automatic inline rendering of PDF documents is reminiscent of 1990s-style security. Thank you, Adobe. Thank you, IE & Chrome & Firefox & Safari, for allowing it to happen.

Why waste time publishing that crap? It's not even good for PR because it only serves to highlight the failure. It's only worth is documenting years of fail and we have Mitre and CERT for that. Every generation of Windows has been the model of bad design and insecurity, including Vista and Vista7. Before M$ reps revised it, /. even had a vista failure tag, for the version to come along after tagging was implemented. Otherwise there would have been a special tag for the XP SP2 disaster.

The SDL is what has contributed to very shitty quality. Of course the raw material, the managers and the engineers have to be mentioned as being incapable.

If jailbreakme can use that exploit then so can someone malicious. Imagine having your phone bricked because you viewed the wrong PDF on some website. The update is a very good thing.

Never mind the fact that OS X, WINDOWS and LINUX all suffered from the same exploit via Type 42 Fonts. Freetype was immediately updated. http://www.kb.cert.org/vuls/id/275247

I was just referring to this technical document: http://www.cert.org/archive/pdf/dranzer.pdf [pdf]

referenced from: http://threatpost.com/archive/blogs/dranzer-fuzzing-activex-vulnerabilities which is linked to from TFA.

Hi,

Do you know if the whitepaper available somewhere for free?

Another link for further information about BFF, is the CERT Vulnerability Analysis Blog, found at https://www.cert.org/blogs/vuls/2010/05/cert_basic_fuzzing_framework.html

-menkhaf

Oh FFS, you couldn't even link to the damn framework?

The CERT Advistory history shows us that when the majority of systems on the internet were *nix, there were lots of exploits for *nix systems... ...and that over time, as more and more home users started populating the net with Windows system, the exploits for Windows grew in number... ...and towards the end of the history, when Windows systems vastly outnumbered everything else on the internet, the great majority of exploits were for Windows systems.

Every time there is a discussion like this, somebody pipes up with what you just said as though it were novel, as though he were mentioning something new that wasn't already well-known (but apparently not well-understood).

You are talking decades ago if you refer to a time when the Internet was mostly Unix systems. That Unix throughout the decades has had many attacks and the security issues that go with them, and has had this amount of time to evolve ways of dealing with them was precisely my point. Read my post again if you missed that. The other part of my point was that this experience has made Unix more resistant and easier to lock down than a modern Windows machine, even though both can be made fairly secure.

To make that more clear, someone who is highly skilled and highly experienced with Windows can secure a Windows server. Someone who is highly skilled and highly experienced with Unix can secure a Unix server. in that sense they're nearly equal. Where they are not equal is the fact that the Unix admin can do it in less time, with standard system utilities, in a more transparent fashion, and often with simpler tools.

The CERT Advistory history shows us that when the majority of systems on the internet were *nix, there were lots of exploits for *nix systems...

...and that over time, as more and more home users started populating the net with Windows system, the exploits for Windows grew in number...

...and towards the end of the history, when Windows systems vastly outnumbered everything else on the internet, the great majority of exploits were for Windows systems.

The UPnP standard lacks any authentication mechanism. Turning it on means anything in your network can open any ports to anywhere it wants. According to this site https://www.kb.cert.org/vuls/id/347812 and here http://www.gnucitizen.org/blog/flash-upnp-attack-faq/ there is even a flash exploit that can be used with uPnP to reconfigure your router. UPnP was dead on arrival. Any router vendor that doesn't ship with it off by default is a retard.

Pretty much.

cf http://www.kb.cert.org/vuls/id/836068

Thanks for the link; I hadn’t seen that source.

Yeah, it looks like they figured out a little more from probably disassembling and reverse engineering the trojan than I figured out from simply playing with the hex values from the network filters given here. (Actually, the Symantec page is linked to from that page... but I didn’t check it out.)

All in all, it’s a really simplistic, primitive hack of a backdoor and it’s hard to believe it wasn’t found sooner. Especially since it had a bug that caused it to go into spinlock sometimes.

I know the parent said XP and 2K only - do not use on Vista.

With Windows Vista, the NoDriveTypeAutoRun registry value actually has the opposite behavior than what Windows has documented. In other words, if you think that you have protected yourself by restricting AutoRun with this registry value, you have actually put yourself at additional risk. We have published details about this issue as US-CERT Vulnerability Note VU#889747. The end result here is that a user may inadvertently execute code by clicking on the icon for a device, such as a USB thumb drive.

details here

Some time back, when USB chargers started to appear at airports, I warned that this might happen. A public charging port is such an attractive attack vector.

Of course, the real problem is Windows's "autorun". It was a truly awful idea to have Windows run any executable that appears on any removable device or medium. That went in (in Windows 95, I think) when CDs were only manufactured by major vendors, before home CD writers or USB storage devices. So it probably seemed "safe" at the time.

Worse was making it very difficult to turn autorun off.

They are. In the 1990s, despite "Windows boxes in the internet" (if you had a SLIP connection), all of the exploits that I saw were targetting SunOS and BSD. They were going after Apache. When Aleph One was writing about buffer overflows, do you think he was working with Windows apps?

This is exactly what these newbies just don't know. (thats right, most of you slashdotters are newbies to the internet.. 5 or 10 years? lol.. newbs)

A small snippet of the security problems on the early internet are in CERT Advisory history. When the internet was mostly unix, unix-like, and VMS machines.. there were plenty of exploits for unix, unix-like, and VMS machines.

All GUI archive managers require a separate "Extract" command (that preserves execute permission), that is different from the default action that is to view a file (without giving it an execute permission even if it is present in the archive).

I have to admit I only tried "tar xvf" to verify that permissions were preserved. Nevertheless, you really think you couldn't get people to actually extract an archive?

For anyone but total newbies it should be obvious that the user should NEVER run anything he downloads unless he is installing some software that is not in a repository -- as root, as his own user or as anyone else.

Yeah, that users won't run crap is well justified.

And because I ran out of words in that sentence before links, here are some more: 1 2 .

To put those into context, those are all links from Wikipedia's "Timeline of Notable Computer Viruses and Worms" from the last decade, including the only two entries on that page from 2009 and 2010. Most of the above had a noticeable amount of mainstream press coverage at the time, and the list includes names like ILOVEYOU, Sobig, MyDoom, and Storm.

Sure, they aren't the scariest worms out there, and over the last few years they haven't been the most damaging. But at the same time, if I got to bet whether a manually-spread trojan is worthwhile, I know which side of that bet I'd take.

Personally I would just turn them into traditional #! scripts with "interpreter" doing what a file manager would, and file manager refusing to execute anything in them unless they are executable.

The .desktop files contain rather more information than just what program to run. How would you deal with that? Specially-formatted comments in the script? Pass the script a command line argument?

Besides, it's not like running scripts without execute permissions is a new concept. "source foo.sh", ". foo.sh", "perl foo.pl", "python foo.py", etc. IMO are all comparable to Gnome looking into the .desktop files on boot to see what to run.

This US-CERT vulnerability note has details for steps for making Adobe Reader safe to use:
http://www.kb.cert.org/vuls/id/508357

As you mentioned, disabling JavaScript helps. But you can also prevent PDFs from opening automatically with the plug-in, and also prevent them from opening automatically with the stand-alone reader. There are some other mitigations there as well.

Of course, this all requires manual configuration. There is no hope for the average home user.

CERT has some suggestions for securing Adobe Reader here:
http://www.kb.cert.org/vuls/id/257117

Note that the above vulnerability note is not this particular vulnerability, but the same mitigations apply time and time again. The mitigations include:

- Enable DEP
- Disable JavaScript
- Disable automatic opening of PDF files by Internet Explorer
- Disable the displaying of PDF files in your web browser

How about the automatic opening of PDF files by Firefox or Chrome?

CERT has some suggestions for securing Adobe Reader here:
http://www.kb.cert.org/vuls/id/257117

Note that the above vulnerability note is not this particular vulnerability, but the same mitigations apply time and time again. The mitigations include:

- Enable DEP
- Disable JavaScript
- Disable automatic opening of PDF files by Internet Explorer
- Disable the displaying of PDF files in your web browser

It really isn't that simple. You could be running *nix or a mac. You might go to the same 3 sites everyday, but never browse new things. Due to the nature of the ways browsers are installed by default (which you imply you are using) you could get infected by even legitimate websites (who resell adspace to unscrupulous buyers) and not even realize it. With no tools, how do you propose to prevent cross-site scripting attacks, Java-script attacks, etc? I actually don't run a/v on personal systems. But I do run daily scans (while I'm at work) with multiple tools. I used to use no software firewall, relying on my strict PIX access-lists to protect me, but now I am using windows 7 and the firewall is so granular it is a good extra step. You are actually a malicious wet dream, someone who thinks they have everything so secure, that as long as you hide the bot/trojan etc well enough, they will never know they are a zombie machine. Just because you haven't been infected in over 20 years doesn't mean you can't get infected tomorrow. So, either you customize your browser intricately (JS, active-x settings, etc) or your just playing Russian roulette. Read this for tips on where you might be lacking. http://www.cert.org/tech_tips/securing_browser/

hits search

367 http://search.cert.org/search?q=advisory+internet+explorer
89 http://search.cert.org/search?q=advisory+netscape
61 http://search.cert.org/search?q=advisory+firefox
20 http://search.cert.org/search?q=advisory+safari
18 http://search.cert.org/search?q=advisory+opera
12 http://search.cert.org/search?q=advisory+lynx

clearly, the fewer number of letters in the name of your browser makes it more secure.