Actually the windows firewall *doesn't* block outgoing connections by default (it does have that capability and it's used to block system services). It's purpose is primarily to prevent worms from propogating via open ports.
Every measurement I've seen indicates that malware authors are profit driven. The reason they find exploits is to drive revenue (in the past this wasn't the case, but for the past 10 or so years it is). Let's take this as a given (if you can find evidence that malware authors aren't profit driven, we can reconsider this, but I suspect you won't).
Finding an exploit costs money - you need to spend your time to find it or you need to pay someone to find it. Either way, you're out cash money - that's an expense for the malware author.
Assuming that the malware author has a limited budget for exploits (which is likely to be true), the malware author is going to want to maximize their return on investment.
Further, let's assume that the cost of finding an exploit is the same on all platforms (that's not true btw - Charlie Miller has said that it's far easier to find exploits on OS X than it is on Windows, but let's just assume that the cost is the same).
If I pay $10000 for a Windows exploit (the amoun of the pwn2own prize), I can target 90% of the computer users out there. If I pay for an OSX exploit, I can target about 6% of the computer users out there, and if I pay for a Linux exploit, I can target about 4% of the users out there (the market share numbers are roughly accurate, but obviously vary by country - for instance OSX has about a 10% share in the US but only 4% worldwide).
So how does the malware author maximize the return on their investment? Obviously they want to chose the one that gets them the most victims for their money. And that choice is Windows - 90% vs 6% vs 4% means that for a given amount of effort, the OS with 90% market share will always return a higher ROI than the OS with 6% or 4%.
The only thing that will change this dynamic is if either the cost for exploits for OSX and Linux goes dramatically down OR if the market share for OSX and Linux dramatically increases.
All software has bugs. Anyone who works in software engineering knows that. It doesn't matter what operating system you're running, they all have bugs. And some percentage of those bugs will result in an EoP. It doesn't matter what operating system - every OS I've known has had EoP bugs in them.
As long as an operating system can run arbitrary applications (in other words, it's not locked down like iOS is), the very nature that allows you to run arbitrary programs allows you to exploit EoP vulnerabilities in the OS.
What MSFT is doing is to release their stuff under CC so that other companies can incorporate the *text* of the SDL and other documents into their internal training materials.
The text is covered under copyright laws and *can* be licensed.
Shatter attacks were only partially fixed? Ummm.. I beg to differ.
Starting with Windows Vista, shatter attacks were completely fixed.
You're right, MSFT didn't retrofit the massive architectural changes to completely fix shatter attacks in Windows XP. But they DID fix the entire class of vulnerabilities.
And on XP, they fixed all the EoP vulns that were enabled by shatter attacks.
This is not to say that there aren't any EoP vulns in Windows. There are. But MSFT patches EoP vulns as quickly as it finds them, just as the various *nix distros (including OSX).
That's not quite true. The 8088 processor could address 1M of RAM, not 640K. But IBM chose to reserve 360K of RAM for video and ROM support in the initial PC architecture.
The 640K value came from IBM's hardware engineers, not MSFT. In fact MSFT sold a PC board for the XT that allowed the machine to address up to 768K or so (up to the start of the CGA video memory).
Not that my comment fundamentally changes your response. The 640K was arbitrary but not the limitations of the addressable space.
You're close but off by an order of magnitude (base 2). On current x86 and x64 machines, pages are typically 4K or 8K and cache lines are typically 32 bytes.
Note the word typically - I know that this can be changed by tweaking various CPU options, but for Windows these are the normal values.
You have examples of a closed source product being shipped with a trojan binary in the official release vehicle?
Not an example of a consumer electronics device that has malware shipped on the device (which isn't a OSS vs COSS issue) but an example of a COSS vendor shipping a trojaned binary on the official release site?
They're different tasks. Unless you're doing 3d imaging, rendering is typically the act of transforming a compressed video to uncompressed video and playing it back. Which should be lockstepped with a realtime clock source since you want the video playback to render in realtime. Actually when rendering video if you find yourself drifting behind realtime, you want to drop frames - that's why video playback turns into a slideshow if it can't keep up (and yes I know that there are other techniques to keep up like rendering at lower bandwidths).
I know the authors of a large number of multimedia codecs and they would *never* refer to conversion from one video format to another as "rendering".
Ummm... I agree with your general point, but the time spent rendering a 1080p video file isn't likely to be an interesting data point. A 30 second clip should probably render in exactly 30 seconds, regardless of machine horsepower. I could see measuring system resources while rendering the 1080p video clip however.
When my company last went through a round of desktop upgrades (6 months or so ago), they got a half a dozen evaluation units from the various hardware vendors and then had a bunch of hardware geeks configure and use them for real-world tasks. So they used them to build some of our biggest projects, enlisted in our source control system, etc. IMHO, real-world use trumps benchmarks almost all the time (it's also notoriously hard to get benchmarks that are reliable).
The thing is that fuzz tesing finds a staggering number of bugs in LOTS of components. Way more than the bugs found by people investigating "complex combinatorial errors".
Why spend months investigating in writing the tests to find all of those permutations when Charlie Miller can write a 6 line python script and turn it loose for a couple of weeks and find dozens of exploitable security holes in products from every vendor out there?
The MSRC also classifies them as vulnerable because it's possible (but REALLY hard) to craft an exploit that can get around DEP, ASLR, GS and Protected Mode and all the other IE/Windows security features.
The MSRC is very conservative in their vulnerability ratings even if it makes MSFT products look bad.
One thing to keep in mind: all that was necessary to reverse engineer the DNS flaw was Dan Kaminski's mentioning that it existed - within a week several researchers had figured it out.
I don't totally disagree with you but there ARE times when just the knowledge that a flaw exists (or a rough idea of where the flaw exists is sufficient to allow others to figure the flaw out).
This folder isn't accessible via the CLI either (from the CLI the folder's just a folder - the name makes it magic to the GUI). So that argument doesn't hold water.
Not quite. NetBEUI is a transport like TCP/IP or SPX. NetBIOS is an API. Like all APIs, it describes a set of semantics on how the underlying networking protocol behaves and because of that it can be layered on top of any protocol.
RFC 1001/1002 describe how to implement the API semantics required by the NetBIOS API on top of TCP/IP.
You're right, I should have been more specific. If a LE officer has a search warrant for the contents of your computer, then he has the right to access the contents of your computer, your right to privacy doesn't apply.
As far as I know, COFEE is only used when you have a search warrant. If you have a search warrant, then by definition there is no right to privacy - by granting the search warrant, the court has said that investigators are allowed to look at your stuff.
In the past, people have tried the "I was framed by the police" gambit before with very limited success - typically courts assume that the people investigating crimes aren't out to plant evidence. I'm not sure that this is a wise decision on the part of the courts but it is what it is.
You're right correlation isn't necessarily causation. But with causation there should be correlation.
There's a great deal of evidence to justify the "most malware is financially driven" assertion (analysis of the types of malware, interviews with malware creators, etc).
Given that most malware is financially driven, the monetization hypothesis follows ("If most malware is financially driven, malware authors will attempt to maximize their financial gain. To do that they target the platform with the lowest opportunity cost.")
This hypothesis is backed up by real-world evidence - the most popular platforms are the most attacked.
A good refutation to the hypothesis would be evidence that in the past 5 years, there was an unpopular platform which was attacked more than the popular platform (OSX or Linux being attacked more than Windows, Silverlight being attacked more than Java, IIS being attacked more than Apache, etc).
If this was a situation where we had corrolation without causation, I'd expect to find counter-examples and I've been unable to find any non-anecdotal evidence over the past 5 years that a minority platform has been targetted more than the majority platform.
Ultimately however it doesn't matter - the reality is that if you run Windows (or Flash or Apache or Adobe's PDF reader), you're at more risk than if you run Linux (or Silverlight or IIS or Foxit). This is true even though OSX has significantly more vulnerabilities than Windows (and it does - just look at the patch roll-ups for OSX or ask Charlie Miller).
Ah, I understand. You're attempting to corrolate defects with attacks and thus asserting that the platform with the most defects is going to have the most attacks.
In some ways you're making a different equally unsupported claim: That the number of defects in Windows is responsible for the number of worms/viruses on that platform.
Unfortunately there's a fair amount of evidence based on the analysis of current malware that refutes your claim.
Fifteen years ago, most malware was written by hobbiests who were looking to create mischief. Todays malware is primarily driven by criminal enterprises and those criminal enterprises are interested in maximizing their profit.
It costs money to develop a working exploit and each exploit can only target a single platforms (exploits which work against Linux aren't likely to work against Windows, exploits which work against Apache aren't likely to work against IIS).
A crook who's decided that they want to make money by spreading malware is going to want to maximise the return on her investment, She wants to target the platform which has the lowest opportunity costs. In this case opportunity cost is based on market size and ease of exploitation.
Since Windows machines make up somewhere around 90% of the population of machines, in order for the opportunity cost of attacking a platform other than Windows, one of two things would have to happen: (a) the market share of the alternate platform would have to go up dramatically or (b) the difficulty of exploitation of the platform relative to the difficulty of exploiting Windows would have to go down.
This analysis holds true for Apache vs IIS. I assert that the opportunity cost of attacking Apache is lower than the opportunity cost of attacking IIS - in fact it's both easier to attack Apache (Apache has demonstrably more vulnerabilities than IIS - see Secunia if you don't believe me) and they have more market share than IIS.
And the data confirms the hypothesis - Apache IS attacked more often than IIS is.
You're right. IIS5 (shipped in *2000* was a cesspool. But IIS6 (shipped in 2003) and every other version is dramatically better.
I know this is/. where it's normal to to use 10 year old data as evidence of the current state of affairs but not surprisingly I disagree (mostly because it helps me make my point:)).
I assert that you should use *current* data to describe current behavior. And the current (as in "at any point during the past 5 years") state of the world is that Apache servers are compromised more often than IIS servers.
Slashdot Mirror
Actually the windows firewall *doesn't* block outgoing connections by default (it does have that capability and it's used to block system services). It's purpose is primarily to prevent worms from propogating via open ports.
Normally I don't feed the trolls, but...
Every measurement I've seen indicates that malware authors are profit driven. The reason they find exploits is to drive revenue (in the past this wasn't the case, but for the past 10 or so years it is). Let's take this as a given (if you can find evidence that malware authors aren't profit driven, we can reconsider this, but I suspect you won't).
Finding an exploit costs money - you need to spend your time to find it or you need to pay someone to find it. Either way, you're out cash money - that's an expense for the malware author.
Assuming that the malware author has a limited budget for exploits (which is likely to be true), the malware author is going to want to maximize their return on investment.
Further, let's assume that the cost of finding an exploit is the same on all platforms (that's not true btw - Charlie Miller has said that it's far easier to find exploits on OS X than it is on Windows, but let's just assume that the cost is the same).
If I pay $10000 for a Windows exploit (the amoun of the pwn2own prize), I can target 90% of the computer users out there. If I pay for an OSX exploit, I can target about 6% of the computer users out there, and if I pay for a Linux exploit, I can target about 4% of the users out there (the market share numbers are roughly accurate, but obviously vary by country - for instance OSX has about a 10% share in the US but only 4% worldwide).
So how does the malware author maximize the return on their investment? Obviously they want to chose the one that gets them the most victims for their money. And that choice is Windows - 90% vs 6% vs 4% means that for a given amount of effort, the OS with 90% market share will always return a higher ROI than the OS with 6% or 4%.
The only thing that will change this dynamic is if either the cost for exploits for OSX and Linux goes dramatically down OR if the market share for OSX and Linux dramatically increases.
All software has bugs. Anyone who works in software engineering knows that. It doesn't matter what operating system you're running, they all have bugs. And some percentage of those bugs will result in an EoP. It doesn't matter what operating system - every OS I've known has had EoP bugs in them.
As long as an operating system can run arbitrary applications (in other words, it's not locked down like iOS is), the very nature that allows you to run arbitrary programs allows you to exploit EoP vulnerabilities in the OS.
That quote doesn't make sense. ActiveX isn't a plugin, it's a plugin model. It's like saying that all vulnerabilities in Flash are the fault of XPCOM.
ActiveX as a technology is no more or less secure than any other plugin model.
The actual PDF says that the 366 vulnerabilities are in ActiveX plugins, NOT in ActiveX.
Did you *read* the article?
What MSFT is doing is to release their stuff under CC so that other companies can incorporate the *text* of the SDL and other documents into their internal training materials.
The text is covered under copyright laws and *can* be licensed.
Shatter attacks were only partially fixed? Ummm.. I beg to differ.
Starting with Windows Vista, shatter attacks were completely fixed.
You're right, MSFT didn't retrofit the massive architectural changes to completely fix shatter attacks in Windows XP. But they DID fix the entire class of vulnerabilities.
And on XP, they fixed all the EoP vulns that were enabled by shatter attacks.
This is not to say that there aren't any EoP vulns in Windows. There are. But MSFT patches EoP vulns as quickly as it finds them, just as the various *nix distros (including OSX).
That's not quite true. The 8088 processor could address 1M of RAM, not 640K. But IBM chose to reserve 360K of RAM for video and ROM support in the initial PC architecture.
The 640K value came from IBM's hardware engineers, not MSFT. In fact MSFT sold a PC board for the XT that allowed the machine to address up to 768K or so (up to the start of the CGA video memory).
Not that my comment fundamentally changes your response. The 640K was arbitrary but not the limitations of the addressable space.
You're close but off by an order of magnitude (base 2). On current x86 and x64 machines, pages are typically 4K or 8K and cache lines are typically 32 bytes.
Note the word typically - I know that this can be changed by tweaking various CPU options, but for Windows these are the normal values.
The kernel did enforce the flags as best as it could. But the processor didn't allow you to have a writable page without the X bit until the 64bit extensions for x86 were designed by AMD. Once processors were available that supported the NX bit (some time around 2004), the OS was modified to support it.
The scandal is that its' been 6 years since that time and apps still haven't caught up with the change.
You have examples of a closed source product being shipped with a trojan binary in the official release vehicle?
Not an example of a consumer electronics device that has malware shipped on the device (which isn't a OSS vs COSS issue) but an example of a COSS vendor shipping a trojaned binary on the official release site?
You've described transcoding, not rendering.
They're different tasks. Unless you're doing 3d imaging, rendering is typically the act of transforming a compressed video to uncompressed video and playing it back. Which should be lockstepped with a realtime clock source since you want the video playback to render in realtime. Actually when rendering video if you find yourself drifting behind realtime, you want to drop frames - that's why video playback turns into a slideshow if it can't keep up (and yes I know that there are other techniques to keep up like rendering at lower bandwidths).
I know the authors of a large number of multimedia codecs and they would *never* refer to conversion from one video format to another as "rendering".
Ummm... I agree with your general point, but the time spent rendering a 1080p video file isn't likely to be an interesting data point. A 30 second clip should probably render in exactly 30 seconds, regardless of machine horsepower. I could see measuring system resources while rendering the 1080p video clip however.
When my company last went through a round of desktop upgrades (6 months or so ago), they got a half a dozen evaluation units from the various hardware vendors and then had a bunch of hardware geeks configure and use them for real-world tasks. So they used them to build some of our biggest projects, enlisted in our source control system, etc. IMHO, real-world use trumps benchmarks almost all the time (it's also notoriously hard to get benchmarks that are reliable).
The thing is that fuzz tesing finds a staggering number of bugs in LOTS of components. Way more than the bugs found by people investigating "complex combinatorial errors".
Why spend months investigating in writing the tests to find all of those permutations when Charlie Miller can write a 6 line python script and turn it loose for a couple of weeks and find dozens of exploitable security holes in products from every vendor out there?
I don't know - I suspect that the firefox team wants to support all platforms equally which would be a problem.
Not only does Microsoft license H.264 in Windows 7, but any application written for Windows 7 can play back H.264 content.
The MSRC also classifies them as vulnerable because it's possible (but REALLY hard) to craft an exploit that can get around DEP, ASLR, GS and Protected Mode and all the other IE/Windows security features.
The MSRC is very conservative in their vulnerability ratings even if it makes MSFT products look bad.
One thing to keep in mind: all that was necessary to reverse engineer the DNS flaw was Dan Kaminski's mentioning that it existed - within a week several researchers had figured it out.
I don't totally disagree with you but there ARE times when just the knowledge that a flaw exists (or a rough idea of where the flaw exists is sufficient to allow others to figure the flaw out).
This folder isn't accessible via the CLI either (from the CLI the folder's just a folder - the name makes it magic to the GUI). So that argument doesn't hold water.
Mod Parent up (hopefully the /. editors will notice this and correct the link to the actual author).
Not quite. NetBEUI is a transport like TCP/IP or SPX. NetBIOS is an API. Like all APIs, it describes a set of semantics on how the underlying networking protocol behaves and because of that it can be layered on top of any protocol.
RFC 1001/1002 describe how to implement the API semantics required by the NetBIOS API on top of TCP/IP.
Navigate to the link in the article: http://www.newscientist.com/blogs/culturelab/2009/12/amanda-gefter-books-arts.php
It was serving up fake anti-virus malware.
You're right, I should have been more specific. If a LE officer has a search warrant for the contents of your computer, then he has the right to access the contents of your computer, your right to privacy doesn't apply.
As far as I know, COFEE is only used when you have a search warrant. If you have a search warrant, then by definition there is no right to privacy - by granting the search warrant, the court has said that investigators are allowed to look at your stuff.
In the past, people have tried the "I was framed by the police" gambit before with very limited success - typically courts assume that the people investigating crimes aren't out to plant evidence. I'm not sure that this is a wise decision on the part of the courts but it is what it is.
You're right correlation isn't necessarily causation. But with causation there should be correlation.
There's a great deal of evidence to justify the "most malware is financially driven" assertion (analysis of the types of malware, interviews with malware creators, etc).
Given that most malware is financially driven, the monetization hypothesis follows ("If most malware is financially driven, malware authors will attempt to maximize their financial gain. To do that they target the platform with the lowest opportunity cost.")
This hypothesis is backed up by real-world evidence - the most popular platforms are the most attacked.
A good refutation to the hypothesis would be evidence that in the past 5 years, there was an unpopular platform which was attacked more than the popular platform (OSX or Linux being attacked more than Windows, Silverlight being attacked more than Java, IIS being attacked more than Apache, etc).
If this was a situation where we had corrolation without causation, I'd expect to find counter-examples and I've been unable to find any non-anecdotal evidence over the past 5 years that a minority platform has been targetted more than the majority platform.
Ultimately however it doesn't matter - the reality is that if you run Windows (or Flash or Apache or Adobe's PDF reader), you're at more risk than if you run Linux (or Silverlight or IIS or Foxit). This is true even though OSX has significantly more vulnerabilities than Windows (and it does - just look at the patch roll-ups for OSX or ask Charlie Miller).
Ah, I understand. You're attempting to corrolate defects with attacks and thus asserting that the platform with the most defects is going to have the most attacks.
In some ways you're making a different equally unsupported claim: That the number of defects in Windows is responsible for the number of worms/viruses on that platform.
Unfortunately there's a fair amount of evidence based on the analysis of current malware that refutes your claim.
Fifteen years ago, most malware was written by hobbiests who were looking to create mischief. Todays malware is primarily driven by criminal enterprises and those criminal enterprises are interested in maximizing their profit.
It costs money to develop a working exploit and each exploit can only target a single platforms (exploits which work against Linux aren't likely to work against Windows, exploits which work against Apache aren't likely to work against IIS).
A crook who's decided that they want to make money by spreading malware is going to want to maximise the return on her investment, She wants to target the platform which has the lowest opportunity costs. In this case opportunity cost is based on market size and ease of exploitation.
Since Windows machines make up somewhere around 90% of the population of machines, in order for the opportunity cost of attacking a platform other than Windows, one of two things would have to happen: (a) the market share of the alternate platform would have to go up dramatically or (b) the difficulty of exploitation of the platform relative to the difficulty of exploiting Windows would have to go down.
This analysis holds true for Apache vs IIS. I assert that the opportunity cost of attacking Apache is lower than the opportunity cost of attacking IIS - in fact it's both easier to attack Apache (Apache has demonstrably more vulnerabilities than IIS - see Secunia if you don't believe me) and they have more market share than IIS.
And the data confirms the hypothesis - Apache IS attacked more often than IIS is.
You're right. IIS5 (shipped in *2000* was a cesspool. But IIS6 (shipped in 2003) and every other version is dramatically better.
I know this is /. where it's normal to to use 10 year old data as evidence of the current state of affairs but not surprisingly I disagree (mostly because it helps me make my point :)).
I assert that you should use *current* data to describe current behavior. And the current (as in "at any point during the past 5 years") state of the world is that Apache servers are compromised more often than IIS servers.