Point / counterpoint. However, I still like the fact that Firefox+NoScript doesn't download "pages full of crap" *at all*. Give me Chrome+NoScript and I'd be one happy camper.:-)
I just checked Chrome out for the first time, and yes it does render pages quickly. But it's no faster (to my naked eye, at least) than Firefox with the NoScript extension running. And since Firefox+NoScript is also blocking scripts, Flash applets, etc. from running, it seems to me that it would be safer than Chrome anyway. YMMV, but I think I'll stick with my Firefox a bit longer.
Are we to believe then that, unlike every single piece of virus-scanning software ever, this binary scanning utility will never encounter a false positive? What happens when it shows some product as containing OSS, but it doesn't?
And with that in mind, even if you *do* identify a product as containing OSS, how do you prove it without access to the source code? The company could simply claim it was a false positive (regardless of whether or not that happened to be true), and you would be left with the burden of proving the tool wasn't flawed.
I run a small computer repair shop, and we first started seeing this ATAPI.SYS virus a few weeks ago. When I would submit it to VirusTotal, it would always come back as clean on every single virus scanning engine - but I could tell it was infected. I even had a computer in here just yesterday which had the infected ATAPI.SYS file, yet it was not detected as such - even when the hard drive was mounted as a secondary drive in another system and scanned with several up-to-date antivirus programs.
The virus itself is actually quite a clever little beast. After infecting the file, it sets the file modification time back to the original date & time, which makes it hard to tell that it's been modified. Also, I've noticed that the byte counts between infected and non-infected versions of the file are almost always identical. But to do that, it appears to be injecting its code into the area normally used to store the file version information. The upshot is, if you check the file properties and there's no file version information (the Version tab under XP or the Details tab under Vista/Win7), there's a good chance the file is infected.
I have not had any computers come in to the shop with the BSOD mentioned in the articles yet, but I'm expecting them at any time...
As I understand it, any file in an NTFS partition can have one or more Alternate Data Streams associated with it, regardless of its type or location. So if you tell someone not to scan something like "Edb.log", does that imply that they should not scan "Edb.log:virus.exe" either?
I have to agree with Trend Micro on this one. Completely skipping specific files in specific directories may prevent performance issues, but it may also make it easier for malware authors to find new hiding places.
Following up on my own post, yes it is DansGuardian that can be configured to block Google searches if Google SafeSearch is turned off. So maybe Microsoft's filter is taking a similar approach?
The obvious thing to try is to turn off the MS filter, check your Google preferences and make sure SafeSearch is enabled, then turn the filter back on and see if the problem persists.
I seem to recall a much older filtering software package (I don't recall which offhand - DansGuardian, maybe?) that will block Google if you have disabled "SafeSearch" in the Advanced Preferences - that is, if you have it set to "Do not filter my search results."
Semantics, semantics. My point was that User-Agent detection is *not* the right way to handle the problem.
As long as the setup program (EXE, MSI or otherwise) handles the detection prior to installation, it meets the requirement I stated: "That way, the setup program could *authoritatively* determine what OS was in use, and block installation onto any invalid systems".
User-Agent "sniffing" is a bad approach under any circumstances - it's too easy, not to mention common, to fake. And since all script-based approaches I am aware of rely on User-Agent detection, they would be effectively broken as well.
If I were doing it, I would put the OS detection in the setup EXE itself. That way, the setup program could *authoritatively* determine what OS was in use, and block installation onto any invalid systems. But we may never know since you didn't finish the download and give it a shot.;)
IE7 is now flagged as a Critical update, whereas the "Update Rollup 2 for Windows XP Media Center Edition 2005" (KB900325) is an Optional update. And guess what? If you install IE7 first - for example, if it is done for you automatically courtesy of Automatic Updates - the KB900325 update fails to install!
Slashdot Mirror
Either I'm not seeing a lot of detail in the linked article, or it's just not there. This one has more info:
BBC News - FBI targets cyber security scammers
http://www.bbc.co.uk/news/technology-13887152
How many commits do you suppose Linus Torvalds has made over the years, between the original BitKeeper revision control and the more recent Git?
Point / counterpoint. However, I still like the fact that Firefox+NoScript doesn't download "pages full of crap" *at all*. Give me Chrome+NoScript and I'd be one happy camper. :-)
I just checked Chrome out for the first time, and yes it does render pages quickly. But it's no faster (to my naked eye, at least) than Firefox with the NoScript extension running. And since Firefox+NoScript is also blocking scripts, Flash applets, etc. from running, it seems to me that it would be safer than Chrome anyway. YMMV, but I think I'll stick with my Firefox a bit longer.
Which just brings us right back to my second point - how do you *prove* it without access to the source?
Are we to believe then that, unlike every single piece of virus-scanning software ever, this binary scanning utility will never encounter a false positive? What happens when it shows some product as containing OSS, but it doesn't?
And with that in mind, even if you *do* identify a product as containing OSS, how do you prove it without access to the source code? The company could simply claim it was a false positive (regardless of whether or not that happened to be true), and you would be left with the burden of proving the tool wasn't flawed.
Of course, there are also the false negatives...
It's gone now.
It's not completely gone - it's just been relocated here.
I run a small computer repair shop, and we first started seeing this ATAPI.SYS virus a few weeks ago. When I would submit it to VirusTotal, it would always come back as clean on every single virus scanning engine - but I could tell it was infected. I even had a computer in here just yesterday which had the infected ATAPI.SYS file, yet it was not detected as such - even when the hard drive was mounted as a secondary drive in another system and scanned with several up-to-date antivirus programs.
The virus itself is actually quite a clever little beast. After infecting the file, it sets the file modification time back to the original date & time, which makes it hard to tell that it's been modified. Also, I've noticed that the byte counts between infected and non-infected versions of the file are almost always identical. But to do that, it appears to be injecting its code into the area normally used to store the file version information. The upshot is, if you check the file properties and there's no file version information (the Version tab under XP or the Details tab under Vista/Win7), there's a good chance the file is infected.
I have not had any computers come in to the shop with the BSOD mentioned in the articles yet, but I'm expecting them at any time...
As I understand it, any file in an NTFS partition can have one or more Alternate Data Streams associated with it, regardless of its type or location. So if you tell someone not to scan something like "Edb.log", does that imply that they should not scan "Edb.log:virus.exe" either?
I have to agree with Trend Micro on this one. Completely skipping specific files in specific directories may prevent performance issues, but it may also make it easier for malware authors to find new hiding places.
Following up on my own post, yes it is DansGuardian that can be configured to block Google searches if Google SafeSearch is turned off. So maybe Microsoft's filter is taking a similar approach? The obvious thing to try is to turn off the MS filter, check your Google preferences and make sure SafeSearch is enabled, then turn the filter back on and see if the problem persists.
I seem to recall a much older filtering software package (I don't recall which offhand - DansGuardian, maybe?) that will block Google if you have disabled "SafeSearch" in the Advanced Preferences - that is, if you have it set to "Do not filter my search results."
Who is "Deaf Leopard"? Are they bigger than Def Leppard?
Semantics, semantics. My point was that User-Agent detection is *not* the right way to handle the problem.
As long as the setup program (EXE, MSI or otherwise) handles the detection prior to installation, it meets the requirement I stated: "That way, the setup program could *authoritatively* determine what OS was in use, and block installation onto any invalid systems".
User-Agent "sniffing" is a bad approach under any circumstances - it's too easy, not to mention common, to fake. And since all script-based approaches I am aware of rely on User-Agent detection, they would be effectively broken as well.
If I were doing it, I would put the OS detection in the setup EXE itself. That way, the setup program could *authoritatively* determine what OS was in use, and block installation onto any invalid systems. But we may never know since you didn't finish the download and give it a shot. ;)
IE7 is now flagged as a Critical update, whereas the "Update Rollup 2 for Windows XP Media Center Edition 2005" (KB900325) is an Optional update. And guess what? If you install IE7 first - for example, if it is done for you automatically courtesy of Automatic Updates - the KB900325 update fails to install!