McAfee Sites Vulnerable To XSS Attack

An anonymous reader notes that this weekend, ReadWriteWeb discovered a security hole on several McAfee sites, which lets any attacker piggyback on the company's reputation and brand in order to distribute malware, Trojans, or anything else. The submitter adds an ironic coda to McAfee's epic fail: "In the 'how to HTML Injection' section, the author provided the four steps needed to execute a simple, no-brainer injection, but unfortunately, exposed a hole in NY Times website when they republished the article. While the author changed the offending text to an image, the Times is still using the original story which redirects directly to ReadWriteWeb [via XSS]." From the RWW post: "During tests this weekend, we discovered the company who claims to 'keep you safe from identity theft, credit card fraud...' has several cross-site scripting vulnerabilities and provides the bad guys with a brilliant — albeit ironic — launching pad from which to unleash their attacks."

Comments

Epic fail

[xming]

Horribly.

Re:Epic fail

[Jaysyn]

McAfail?

Re:Epic fail

[Lobster Quadrille]

A much more serious issue- in the control panel for their web application scanning service was published yesterday.

http://skeptikal.org/2009/05/epic-failure-from-mcafee.html

This XSS is cool, but it's not news. I've been documenting McAfee web vulnerabilities for a year now. Rest assured, there are many more, some of which will be published later this week.

Hmm.

[Phroggy]

Yikes. I wonder if any of my code has that vulnerability. I don't think so. I try to make sure I run all user-submitted text through something to escape those kinds of characters before sending it back to the browser as HTML, but it's possible I could have missed something somewhere. The only time I don't do this is if the user-submitted input is first passed through an input validator that should reject anything containing dangerous characters (for example, a valid e-mail address cannot contain HTML tags, so if I reject all but a valid e-mail address, then I don't need to sanitize the e-mail address). But how can I be sure I haven't missed anything somewhere?

The only way I could be sure is if I did a thorough audit of all my web site code, and I really don't want to go through that hassle. It's probably fine. I've never had an XSS attack used successfully against any site I've built. Certainly not one that was using SSL. So let's just assume that this trend will continue!

Right?

Re:Hmm.

[6Yankee]

The only time I don't do this is if the user-submitted input is first passed through an input validator that should reject anything containing dangerous characters (for example, a valid e-mail address cannot contain HTML tags, so if I reject all but a valid e-mail address, then I don't need to sanitize the e-mail address). But how can I be sure I haven't missed anything somewhere?

Ouch. I can disable the client-side validation entirely. I can also write my own form and send you anything I like.

Sanitize everything.

Re:Hmm.

[Swizec]

For the safety of your users, I do hope the sanitization happens on the server-side otherwise ... yikes. Then again, some clients simply don't pay enough for sanitization and I just dump anything someonen posts right back to the page. Easier spending an hour every two months deleting "spam" than spending time making sure everything gets properly sanitized.

Yes I'm a lazy coder I know, but fuck it, you get what you pay for.

Re:Hmm.

[growse]

I find it easiest to not validate anything on input, because I don't know what my output is necessarily going to be - could be HTML, could be PDF (for example). If I am outputting to non-HTML I don't want to wade through HTML-encoded soup to get something sensible back out.

If I'm outputting to web, I then always validate / encode *all* content, usually using something like the Microsoft AntiXSS library. This stops user-inputted markup from being rendered, but it also stops markup that's been maliciously inserted into your database from being remembered. Remember the SQL injection attack that appended a javascript snippet to every field it could find? It was looking to do an XSS attack.

If you need to chuck out user-generated markup, make sure you contstruct your whitelist and ruleset very carefully.

Re:Hmm.

[Anonymous Coward]

Informative? Where does he say it's client-side?

I try to make sure I run all user-submitted text through something to escape those kinds of characters before sending it back to the browser as HTML

Guess where he sends it back from, numbnuts.

Re:Hmm.

[6Yankee]

I would have thought the clue was in this part: user-submitted Unless, of course, his users all have logins on his server.

Re:Hmm.

[AlXtreme]

Yes I'm a lazy coder I know, but fuck it, you get what you pay for.

Do it right, or don't do it at all.

I'm all for cutting corners when dealing with stingy clients (which tend not to be clients for long) so I get your way of thinking, but basic security shouldn't be one of the corners to cut. In the end it will be worthwhile to simply add a bit of code to sanitize user input to avoid all the hassle you'll get in the long run.

If you are spending an hour (of your own or billed) every two months for cleaning up crap, next time please spend two hours and add some validation. Keep on billing said client for spam cleanups for all I care.

Every time a viewer sees spam it makes your work seem poor. Even a lazy coder knows when it will cost him more work in the long run.

Re:Hmm.

[galego]

Hope you're not trying to "enumerate the bad" (i.e looking at $foo ~= /<script/i in the input ... or even '<'). There are lots of ways to escape such validators. A great resource on some is here: http://ha.ckers.org/xss.html I say, unescape everything back to the browser (even email addresses). OWASP has a good resource: http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

Re:Hmm.

[daveime]

User submitted implies that he's talking about server side validation of the received POSTed data. Also he specifies that he is properly escaping dangerous characters before sending the response BACK to the browser.

No where could it be interpreted as client-side validation.

Re:Hmm.

[wazzzup]

User-submitted doesn't imply client-side (javascript) validation. I always sanitize user-submitted content via PHP. Of course, replace PHP with Ruby, ASP, Java or whatever other server-side language you're using. It's pretty hard for a user to manipulate server-side code without a login shell to the webserver or a really brain-dead server setup.

Re:Hmm.

[Anonymous Coward]

> (for example, a valid e-mail address cannot contain HTML tags, so if I reject all but a valid e-mail address, then I don't need to sanitize the e-mail address)

Don't be so sure about that...

Especially not when a valid email CAN have a lot of funky things in it, even comments.

Re:Hmm.

[Phroggy]

User submitted implies that he's talking about server side validation of the received POSTed data. Also he specifies that he is properly escaping dangerous characters before sending the response BACK to the browser.

Yes, this is precisely what I meant.

I normally implement server-side input validation first, test it, then add client-side input validation in JavaScript.

On the server side, once it's been through input validation, then anything that needs to be sent back to the browser is escaped (run through a function that converts characters like greater-than/less-than symbols to HTML entities, etc.), but I often skip this for data that is known to be safe because it would have failed input validation if it wasn't (e.g. e-mail addresses).

No where could it be interpreted as client-side validation.

Somehow it would appear that you're mistaken. ;-)

Re:Hmm.

[Phroggy]

I find it easiest to not validate anything on input, because I don't know what my output is necessarily going to be - could be HTML, could be PDF (for example). If I am outputting to non-HTML I don't want to wade through HTML-encoded soup to get something sensible back out.

What I mean by input validation is aborting with an error if the user has submitted invalid data, e.g. entering "foo" in an e-mail address field. Nothing is encoded or escaped at this point. If I need to store it in a database, the data is stored as-is, using the Perl DBI's automatic escaping feature to make sure SQL injection attacks aren't possible (I can think of one occasion when this wasn't adequate and I had to wring my own routine). Whatever else I need to do with the data, any necessary escaping gets done only as the data is being used, it's never stored that way. If I need to send it back to the browser, HTML escaping doesn't happen until I actually print the HTML, or immediately before.

If I'm outputting to web, I then always validate / encode *all* content, usually using something like the Microsoft AntiXSS library. This stops user-inputted markup from being rendered, but it also stops markup that's been maliciously inserted into your database from being remembered. Remember the SQL injection attack that appended a javascript snippet to every field it could find? It was looking to do an XSS attack.

That's a very interesting idea. Because I use Perl's DBI, I don't normally worry about SQL injection, because I so rarely include a raw variable in a query string (and I'm very careful if I do - for example, I might use a variable that's looping through a list of field names, but the list isn't user-submitted, it's hard-coded into the script).

If you need to chuck out user-generated markup, make sure you contstruct your whitelist and ruleset very carefully.

Yes, I think I have done that. However, this sort of thing is very easy to get wrong, and one little slip can result in disaster. Hopefully I've done everything correctly.

Re:Hmm.

[Phroggy]

> (for example, a valid e-mail address cannot contain HTML tags, so if I reject all but a valid e-mail address, then I don't need to sanitize the e-mail address)

Don't be so sure about that...

Especially not when a valid email CAN have a lot of funky things in it, even comments.

Hmm. It looks like you're right. On sites where I've written my own validation code it won't be accepted, but where I've used a CPAN module, it might be. I'll have to see if that's a problem anywhere.

Normally characters like greater-than/less-than symbols are not permitted, but the local-part (left of the @ symbol) can be quoted, and if it's quoted, it can contain them. Spaces are also allowed. So, "<script>alert('foo');//</script>"@example.com is technically a valid address. That's disturbing.

Re:Hmm.

[growse]

What I mean by input validation is aborting with an error if the user has submitted invalid data, e.g. entering "foo" in an e-mail address field. Nothing is encoded or escaped at this point. If I need to store it in a database, the data is stored as-is, using the Perl DBI's automatic escaping feature to make sure SQL injection attacks aren't possible (I can think of one occasion [phroggy.com] when this wasn't adequate and I had to wring my own routine). Whatever else I need to do with the data, any necessary escaping gets done only as the data is being used, it's never stored that way. If I need to send it back to the browser, HTML escaping doesn't happen until I actually print the HTML, or immediately before.

If more devs coded like this, I would be a happier person :) The number of times I see devs coding themselves into a corner when they don't even understand why they're doing what they're doing is horrific.

That's a very interesting idea. Because I use Perl's DBI, I don't normally worry about SQL injection, because I so rarely include a raw variable in a query string (and I'm very careful if I do - for example, I might use a variable that's looping through a list of field names, but the list isn't user-submitted, it's hard-coded into the script).

SQL injection isn't the only way an attacker could stick data in your database, but it's probably one of the easiest if you're vulnerable. The code for the MS library is fairly trivial, you can look at it with a .NET reflector and then implement in any language you want. Basically, it says that if the ASCII code of the input character is between a certain safe range [A-Za-z0-9] then return as is. Any other character, return the HTML-encoded version.

Re:Hmm.

[Anonymous Coward]

Yes I'm a lazy coder I know, but fuck it, you get what you pay for.

Do it right, or don't do it at all.

I'm all for cutting corners when dealing with stingy clients (which tend not to be clients for long) so I get your way of thinking, but basic security shouldn't be one of the corners to cut. In the end it will be worthwhile to simply add a bit of code to sanitize user input to avoid all the hassle you'll get in the long run.

If you are spending an hour (of your own or billed) every two months for cleaning up crap, next time please spend two hours and add some validation. Keep on billing said client for spam cleanups for all I care.

Every time a viewer sees spam it makes your work seem poor. Even a lazy coder knows when it will cost him more work in the long run.

I doubt the viewers know it is his work, so he has no reputation to lose. And if he gets paid to clean it up, he has an actual DISincentive to fix it unless he has more work than he can handle, unlikely in this climate, even for lazy workers.

GP said it best. You get what you pay for, in this case bad management who doesn't control costs. That's management's fault, not the admittedly lazy coder's.

Re:Hmm.

[joost]

Yes I'm a lazy coder I know, but fuck it, you get what you pay for.

Holy fuck how lazy do you have to be to NOT put htmlspecialchars() around browser-facing strings?? In Rails it's even simpler. Come on!

Re:Hmm.

[Swizec]

Very lazy when you're using rich WYSIWYG editors and want html to be parsed.

Re:Hmm.

[Thinboy00]

OP means he copies the offending URL to the clipboard, mungs it, and THEN pastes it to the location bar (URL bar ("awesome bar" in firefox)). JS is not involved at all.

Eat their own dog food

[agristin]

Either they don't use McAfee secure ( http://www.mcafeesecure.com/us/ Probably the right website, who knows really ), or their own dog food is garbage.

Either way it is bad gaffe. XSS is pretty well known in security circles. And this mistake is a relatively simple one (output validation or output filtering? please. After you read the linked article, you'll be even more sad they didn't catch this.

Re:Eat their own dog food

[Anonymous Coward]

What happens a lot (and I believe what happened in this case) is that sites were contracted out, then whoever deployed them didn't go through the standard security processes for site deployment. It's not like this was the main partner site. I believe Kaspersky had a nearly identical thing happen to them a few months ago.

Re:Eat their own dog food

[Anonymous Coward]

Either they don't use McAfee secure ( http://www.mcafeesecure.com/us/ Probably the right website, who knows really ), or their own dog food is garbage.

It is garbage. McAfee Secure is formerly HackerSafe (aka ScanAlert) that doesn't detect against XSS because it's bad for business.

Syndicated version on NYT site

[Anonymous Coward]

http://www.nytimes.com/external/readwriteweb/2009/05/04/04readwriteweb-mcafee-enabling-malware-distribution-and-fr-12208.html

executes the code and redirects to readwriteweb.com

Distribute?

[Haiyadragon]

Sure, I can use this to inject code into the html that is then processed by my webbrowser. But how I can use this type of XSS to distribute anything? The worst thing I can do is still only happening on my pc.

Re:Distribute?

[Hurricane78]

Well, it injects code that can change the download link to a trojan that wraps the original thing. In your webbrowser.

In sites with logins and other user-private data, well, let me take Slashdot as an example.
Imagine someone got some evil code into the site, that your browser would load and execute.
That code could quickly put the entire page into a frameset, with the outside being the control channel.
Then, while you were reading, it would load your unprotected profile in the background, and change your sig to that same evil code (or a link to it). So everybody else would get it too.
Then it would do a complete scan of your internal network, possibly detecting your router, and its ports. (All possible with JavaScript. Been there, seen it.)
You could click on a link in /., and the frameset would survive. You could even keep that tab open all day long, effectively making you a zombie host.
In the process, it would accept arbitrary commands from the controlling system. If you happen to go on the site or your router, it could for example try things in there too, like set an external control IP to the controlling system, and gain full access to your own network. (Unlikely, but I've seen it happening.)

And all this is just the tip of the iceberg.

Re:Distribute?

[daveime]

I think the parent's point is that the data submitted to McAfee's database and subsequently rendered back out on the following page is PERSONAL data belonging to you, and is unlikely to be seen by anyone else.

It's like making a purchase online ... at what point would anything you submitted (name, address, credit card number etc), be rendered back out for a third party to view ?

Notwithstanding it's a poorly designed website, the mitigation is that anything YOU submit is unlikely to cause a third party to fall foul of the XSS exploit.

And security researchers just love sensationalising these things (it gets them more business after all) ... for me it's a bit of a non-story to be honest.

Re:Distribute?

[Haiyadragon]

Sure an arbitrary website can present the vulnerable website with injected code, but this code can't do anything javascript cannot already do directly. Which, in a reasonably secure browser, is not a whole lot.

Re:Distribute?

[Cow Jones]

Then it would do a complete scan of your internal network, possibly detecting your router, and its ports. (All possible with JavaScript. Been there, seen it.)

I'd really like to see a source on that. In any reasonably current browser, you can't even read the local IP address with JavaScript [you can, if you use applets, but that's something quite different]. I highly doubt you could do anything like you describe with JS alone, unless the user happens to be running ancient software without security updates. In that case, he gets what he deserves.

CJ

Re:Distribute?

[Hurricane78]

Come on. That one is nearly too simple to answer: Is there any way at all, to submit non-personal data on that site?

If yes, then the code that is rendered personally for you can submit that too.

Also, I have a tip for you: People who try to emphasize words by writing them all-caps, look like aggressively screaming idiots. Not what you would want to have associated with your arguments, if you really want to convince others. You know... offended people have the habit of not taking you very serious, no matter if your arguments were good or bad.

Re:Distribute?

[daveime]

I will try to not use capitals in future, and find some other means of adding emphasis ;-)

Re:Distribute?

[Lobster Quadrille]

1) You make a purchase, inject javascript into your address. The administrator goes to the website to print shipping labels. Now you control the administrator.

2) You log in. Later that day, you're visiting evil.com, which loads the site in the background, with payload, and slurps data off of it.

Sure, but the camel was already broken...

[wild_quinine]

I found an old USB stick the other day with McAfee's superdat (definitions and engine update) file circa 2006. That's only two and a half years ago. It was a real wake-up call. The superdat was just over 6mb in size.

These days you can't fit the application and latest superdat onto a 128mb stick - and when I tell you that the application in only 20mb in size, you'll realise what a change this is. Their updates been spiralling out of control for two years. Now, some may argue that there's a lot more malware out there now, and I won't disagree. But I will say this: McAfee hasn't been getting significantly better as far as I can tell, and none of the other major players seem to have experienced this definitions file explosion, ergo McAfee is doing something wrong.

Furthermore, their version 8 enterprise has one of the worst failures I've ever seen for a virus scanner, which is hilariously related to the above. The application no longer knows how to handle its own virus defintions catalog: I'm not sure whether that's the sheer size, or the number of entries, but either way the update fails because of it. But get this: it says that the update has succeeded!

Can you imagine a more epic fail for a virus scanner than saying it's up to date, but being wrong? Neither could I, till I read the news today.

So long McAfee, I hope you enjoyed your time with the big players.

Re:Sure, but the camel was already broken...

[drinkypoo]

Furthermore, their version 8 enterprise has one of the worst failures I've ever seen for a virus scanner, which is hilariously related to the above. The application no longer knows how to handle its own virus defintions catalog: I'm not sure whether that's the sheer size, or the number of entries, but either way the update fails because of it. But get this: it says that the update has succeeded!

They were just trying to catch up to Norton/Symantec Antivirus, which has had this feature since version 7 (I ran into it ENDLESSLY at Yuba College.) The fix was to reinstall windows (ever tried manually removing norton? heh heh) and run virus def updates manually. The problem remained at least until version 9, which is what they were running when I quit.

Re:Sure, but the camel was already broken...

[digitalchinky]

AVG was another one that jumped up pretty massively in file size. Perhaps not quite as fast though. If memory serves, version 6 was somewhere around the 5 megabyte size just a few years back. The latest, version 8, is a tad over 60 megabytes. I bet there is some cruft left over in those virus definitions. Probably more than a few marketing PHB's thinking that a huge file size must mean it's better.

Re:Sure, but the camel was already broken...

[superFoieGras]

AVG seems to have gone more an more popular. Then if you want to look efficient you need at least a 50Mb paint job...

Re:Sure, but the camel was already broken...

[TheThiefMaster]

Back in the day I had hilarious fun trying to use Norton's (I think) tool for making a bootable virus scan disk.

It put the bootable OS and virus scanner on one floppy, and the virus definitions file on another.

Except that the virus definitions file didn't FIT on a "1.44MB" floppy.

Re:Sure, but the camel was already broken...

[MagicM]

Can you imagine a more epic fail for a virus scanner

Can you all please stop saying "epic fail"? I know /b/ is down, but damn.

*chan memes? In MY Slashdot summaries?

[Anonymous Coward]

It's more likely than you think.

Re:Antivirus on Windows

[daveime]

It's a web page exploit, wtf does it have to do with Windows ?

Redirects work in all browsers, and while I can't speak for Firefox, at least MSIE 8 will warn you of a possible cross domain phishing attempt.

McAfee also make products for Linux and Apple you know.

Just another anti-ms troll who can't wait to make his mark on /.

Winslows is teh suxxors !!!

How do we thow...

[Anonymous Coward]

that *this* isn't a virus targeted at people who read articles about viruses?

Re:How do we thow...

[daveime]

Speaking of viruses, that's a nasty cold you've got there.

How do we thow

Wait one minute.

[Lifyre]

Is it just me or was anyone else surprised that McAfee had any reputation or brand left to piggyback upon? I though McAfee was generally worse than most viruses...

Re:Wait one minute.

[rindeee]

Actually, their enterprise class stuff is outstanding. I don't use any of their "home user" level stuff, but for my money, McAfee beats the pants off of other high-end offerings. Their IDS, mail filtering, etc. (much of it acquired over the years) is outstanding product.

Re:Wait one minute.

[Anonymous Coward]

at least, its not norton

Re:Wait one minute.

[Taibhsear]

Seriously. I constantly fix computers for my friends and family and at least 90% of the time the problem with their computers is mcaffe or norton bogging down their systems. I throw on avg and/or malwarebytes instead. I've never even seen mcaffe or norton find a virus or malware before. AVG and malwarebytes I've gotten countless hits with.

Re:Wait one minute.

[jotok]

The same is true of the other vendors. Symantec and Mcafee are both largely acquisitions companies with great enterprise stuff and crappy consumer stuff.

Re:Antivirus on Windows

[Anonymous Coward]

Redirects work in all browsers, and while I can't speak for Firefox, at least MSIE 8 will warn you of a possible cross domain phishing attempt.

Firefox + noscript will block XSS attempts.

Not in my web browser

[Viol8]

"In your webbrowser."

I think you meant "In your web browser as long as you're running Windows. If you're not running Windows you really don't need to care - just have a good laugh instead".

Re:Not in my web browser

[Canazza]

the XSS affects all browsers, that's the point. It can be easilly used as part of a phishing scam, where the only defence is a clued-up user. And Linux users *may* end up at Mcafee's site, if they're running this or this

Re:Not in my web browser

[Viol8]

XSS affecting all browsers is irrelevant if its main line of attack is a win32 trojan. Can't say I'm bothered about javascript malware , its a crippled language and will exit as soon as I close the tab anyway.

Default for my School

[EmperorArthur]

rant:
At my college you aren't allowed on the network if you run windows and don't install Cisco crapware.

This crapware checks for an antivirus, and if you don't have one the school will install one for you.

Guess what they install McAfee 8.5 as their licensed AV software.

McAfee has horrendous trouble updating its definitions, especially when it's used in conjunction with Cisco crapware. Its actual usefulness is a joke, and has anyone ever tried to whitelist a program with it.

Re:Default for my School

[Anonymous Coward]

If you're so clever, why are you still in school?

XSS

[ItsPaPPy]

there is a really good post on it here http://www.xssed.com/news/92/XSS_Iframe_injections_and_XMLHTTP_post_request_errors_on_McAfee_sites/ and http://www.xssed.com/archive/domain=mcafee.com shows sites in the past XSSable http://xssed.com/ keeps track of a lot of XSSed sites

Awesome...

[hesaigo999ca]

finally forced some accountability for big AV company...hope they stagger and sway before falling down. I really hope they go bankrupt, because everyone wants their money back for their product, and this sets a precedent to all other AV companies....stop screwing us!

conficker

[Drantin]

So, the solution to this is obviously to just install conficker/downadup on your computer. McAfee's site should no longer be available after that.

Don't worry, McAfee is safe

[Opportunist]

I've been trying to sway my boss for months. We're using McCrap. I've been in the malware biz before I turned into a manager type (yeah, the whole three-piece suit and other baggage... don't hurt me please, I'm still one of the good guys), and I know what to expect from McA.

I showed him that page. He looked blank at me and shrugged. He's "pretty sure that others ain't better than that". And "that this could happen to anyone". And that "they should protect us, whether they're secure themselves..." and so on.

It's just SO frustrating to explain a horrible security problem to people who neither understand security nor care about it. Especially when change means expense.

The train of thought is simple. We bought "something" that is supposedly protecting us. So we've done our share, we paid our dues, we did what we could do. Whether we're really protected? Doesn't matter, what matters is we can't be sued for negligance.

Re:Antivirus on Windows

[Yvanhoe]

You have no reason to go to MacAfee pages if you don't use their products or plan to do so. You have no reason to use them if you are not on windows.

McAfee is still pretty terrible

[dzym]

I work IT for a college that used to push out McAfee Enterprise to all desktop machines. We
switched our license/subscriptions/contract and pushed out Sophos right now.

McAfee would randomly mysteriously break and be completely unable to update its scanning engine or dat files, and out of THOUSANDS of desktop machines we'd have a bunch of them with definitions from months or years ago. Which ones? Hell if we knew!

Out of this latest Conficker crap imagine our surprise that McAfee simply didn't recognize the USB variant! We verified that Sophos in fact detected Conficker and immediately pushed Sophos to all of the computer labs and instructor stations.

And I still gotta remember back to the silly password-"protected" FTP of NAI/McAfee software.

So basically, McAfee is truly incompetent and I'm glad to see it gone on our computers.

Re:McAfee is still pretty terrible

[Nos.]

You must not be using ePO, or using it correctly. I'm new to it, and running an old version (3.6.1) but I can tell you in a matter of minutes, how many machines (of around 5000) are running the most current dat files, and how many aren't. I can very quickly get a list of machines running any version but the most current (though I usually only care about machines that are more than a few versions out of date).

If the engine does happen to break (which has happened, but is pretty rare), I can use ePO to reinstall it on the client machine.

McAfee detected Conficker just fine for us. Admittedly, their Conficker network scan tool didn't work well for me, I used the beta version of Nmap to do that (zero infections across our network).

On an enterprise level, I'm quite impressed with McAfee so far. There've been a few hiccups for sure, but I've seen much worse. We'll see how my upgrade to ePO 4 goes in the coming months.

Re:McAfee is still pretty terrible

[Slashcrap]

McAfee would randomly mysteriously break and be completely unable to update its scanning engine or dat files, and out of THOUSANDS of desktop machines we'd have a bunch of them with definitions from months or years ago. Which ones? Hell if we knew!

You have thousands of machines but didn't use ePO? McAfee does suck, but you are fucking terrible.

What's the big deal?

[pedalman]

An anonymous reader notes that this weekend, ReadWriteWeb discovered a security hole on several McAfee sites, which lets any attacker piggyback on the company's reputation and brand in order to distribute malware, Trojans, or anything else.

Isn't McAfee already considered to be malware? Perhaps they hate the idea of competition in the malware distribution business.

Great idea.

[RulerOf]

Firefox + noscript will block XSS attempts.

Yes. We know.

Firefox + NoScript will block [INSERT WEBSPLOIT HERE].

NoScript also kinda prevents nearly everything on the web from working as intended, and is not a solution. Please shut up about how much you think it rocks.

Re:Great idea.

[someone1234]

You can whitelist mcafee scripts.

Re:Great idea.

[Dark_Gravity]

NoScript also kinda prevents nearly everything on the web from working as intended, and is not a solution. Please shut up about how much you think it rocks.

You just aren't using it correctly.

Re:Great idea.

[Anonymous Coward]

Not necessarily.

You can have NoScript set to Globally Allow Scripts and still block most XSS attempts.

There are occasional difficulties with this (wherein NoScript will block something that you *wanted* to happen), but for the most part, this is easy enough to figure out, and you can tell NoScript to stop blocking it and it will.

However, a setup like this requires some additional initial configuration.

(I'd like it a lot better if NoScript would make a "Allow All but watch out for XSS" setting that was easy to implement out-of-the-imaginary-box, but I don't think it's likely to happen.)

Re:Great idea.

[Thinboy00]

Not for XSS, which only applies to "untrusted attacks trusted", and doesn't work if there are no "untrusted".

I've never trusted McAfee

[fast turtle]

after I spotted a virus that was commonly in the wild and they couldn't identify it in my email 10 years ago. In fact I was very disappointed that McAfee didn't block the damn virus with at least a warning as it was a simple executable file. Norton on the other hand properly identified the virus and warned me about the executable nature of the file. Based on that past experience, I've never trusted McAfee as being worth a damn.

Re:Antivirus on Windows

[thePowerOfGrayskull]

Redirects work in all browsers, and while I can't speak for Firefox, at least MSIE 8 will warn you of a possible cross domain phishing attempt.

Firefox + noscript will block XSS attempts.

It will also conveniently unblock advertisements, overriding adblock plus in order to let you see that advertising content that the developers feel you should see. So much for smug superiority...

Re:Antivirus on Windows

[AlexBeck]

Still, what the fuck does this have to do with windows?

SQL injection

[Anonymous Coward]

4years ago they were vulnerable to sql injection. now its xss surely for more than 1year... There's more for sure

Re:Antivirus on Windows

[Binestar]

That was changed, they no longer unblock and have posted a front page apology for the change in the first place. http://noscript.net/

Important update for Adblock Plus users: Version 1.9.2.6 automatically and permanently removes the cotroversial NoScript Development Support Filterset deployed with NoScript 1.9.2.4. I sincerely apologize with ABP users. Even though information about its presence and how to remove it in two clicks was given on the AMO install page, on this site's install page, on the release notes landing page and in the FAQ, not including a prompt asking for explicit permission beforehand from the start has been a very bad omission, and I want all the ABP users who felt betrayed to know how much I'm sorry for that. As a sign of good will and repent, current NoScript 1.9.2.6 completely removes the ABP filterset on startup with no questions asked. Thanks for your patience.

-- Giorgio

Update: More apologies and background facts on author's blog Hackademix.net.

Re:Antivirus on Windows

[thePowerOfGrayskull]

Thanks for the info. Sigh. We will now be returning you to your regularly scheduled smug superiority.

That's nice.

[Orbijx]

This promises to be an interesting bit of crying material for some customers that I'll deal with here.

I get callers using McAfee, and they tend to get infected for some reason or another (I don't care why -- not in my pay grade). Apparently, I should be expecting to hear over the next few days, "Hey, I clicked on a link in my email to upgrade my McAfee, and I think I have a virus. :("

Why?

Because SHEEPLE CLICK ON ANYTHING.

Fortunately, it looks like McAfee has rushed to put some caulk in those holes, so the flow of sheep will be minimal, but still.

Re:Antivirus on Windows

[Hamoohead]

and while I can't speak for Firefox, at least MSIE 8 will warn you of a possible cross domain phishing attempt.

Firefox with noscript plugin certainly does.

Re:Antivirus on Windows

[Achromatic1978]

That's not an apology, that's a joke, "Even though we did this and we did that and even though it did this and it did that, I want you to know I'm sorry I didn't ask even more".

Re:Antivirus on Windows

[Burpmaster]

The relevance is that on Windows security depends on downloading security tools off the web through a web browser where you're vulnerable to any browser exploits and spoofing attacks. Hence the phrase "doomed if you do, doomed if you don't."

On a Linux distro, you usually install software through a package manager that authenticates the package before installing it. Not that you need to add anything to make it secure...

Re:Antivirus on Windows

[Binestar]

The guy is a coder, not an english major. Read his blog post that is linked to there. It's a legitimate apology even if he's not the best at expressing himself.

Re:Antivirus on Windows

[thexile]

Continuing to smug, fanboy.

Re:Antivirus on Windows

[Binestar]

Not a fanboy, just willing to take something at face value if there is no reason not to.