I looked through the cases of the past 5 years, yes. No I didn't make a statistical analysis, it wasn't necessary as it wasn't even close. If you feel otherwise, please go ahead, but even looking at the first few pages should have given you a pretty good idea.
Cases against companies like: Microsoft Visa American Express Coca-Cola Chrysler Delta Airlines Oracle Texas Instruments Qualcomm Intel Apple
Did you actually look through those cases? I doubt it, because you would find: A) There is an unproportionally large number of cases against American companies . B) Of the verdicts, those cases raised against American companies have an unusually higher conviction rate compared to the cases against non-American companies. C) When an American company is found guilty, the fines are higher than those against non-American companies.
For example, the two largest fines the EC has levied, were both against American companies (Intel, Microsoft).
First, most people wouldn't be running Vista Pro, they'd be running the less expensive Vista Home. Secondly, since you can't move the OS to your next machine, it's more comparable to an OEM version of Vista Home.
Vista Home Basic OEM: $84 (newegg) Windows 7 Home OEM (full version): $84 **Projected based on vista prices at newegg Total: $168
Mac OS X 10.4: $129 Mac OS X 10.5: $129 Mac OS X 10.6: $29 Total: $287
That is still debated, apparently. The FSF believes as you do, while many others, including OSI say otherwise. Personally, I side with OSI's interpretation.
the iis worker proccess when accepting a connection goes ahead and establishes a server side out bound port to talk back to the client
No, it doesn't, and it won't. Please test this yourself before coming back and arguing this again.
and yes iis will send info out one ip that was sourced on a diffrent - and it will lie about the source.. trust me if you do multi home without BGP and your up stream providers actualy check header info you will see this happen.
No, it won't. I am currently multi homed across many networks, and I tell you without a doubt that is incorrect. You are most likely confusing the difference between a network interface and an IP address.
my logic isn't flawed - it just how iis behaves - and the whole conversation on this branch is WHY apache is vulnerable and why IIS isn't (or at least not normally)
Yes, this whole conversation is why apache is vulnerable and IIS isn't, but the reasons you gave are wrong.
and as for SSL being bound to an IP your right it doesn't have to be a single ip it can be a range. BUT if you are hosting more than a single SSL site on the same server you must assign each one their own ip(s) instead of using the "any available" option under iis - which limits the number of available address and there for ports for it to source a reply from
Again, a very limited view of what happens, but mostly correct. "it can be a range" is incorrect, as you yourself say, it can be "any available", which is not a range. So you've contradicted yourself. The most common behavior is to assign each site their own IP address, but that is only so that you can use the default incoming port. You CAN assign multiple sites to the same IP address, each residing on it's own port, and things will function just fine. Unfortunately, poorly designed (likely corporate) firewalls may refuse to connect to that port, but that's another issue.
Your understanding of how TCP connections work is very flawed.
well the connection limit for a single host is the number of available ports for outbound traffic (to return data to the client)
Incorrect.
by default (from memory here) i want to say IIS is set up to use ~4k ports for outbound - i do know that can be changed to allow ports 1024+ to be used meaning the number of avaliable ports would be ~64.5k
Sort of, but you are talking about the ports a client a may to establish a connection to a server. This has no use at all for a server that is already bound to a single port.
and that is per host ip - and unless you have the site bound to a specific host ip address (instead of using site headers - iis will respond on an alternate ip (if it has one) when another is out of ports (infact i think it round robbins - i can't remember)
Incorrect. If the server were to respond on a different IP (or port for that matter) than the one the client initially requested, it would be discarded.
Where this could be a problem for iis is with SSL as SSL has to be bound to an IP and the max amount of ports for that IP is going to be less than the number of ports that the client can send from. So yes this type of exploit could cause an outage in IIS - it is much less likely (based on default config) than apache - and is only realistically likely when trying to attack an SSL supporting site. (like they are hard to find)
Completely incorrect. SSL does not *HAVE TO* be bound to an IP (although it usually is). The max ports is irrelevant, it will only use one. No, IIS wouldn't be vulnerable. The rest is garbage.
About the only IIS server that this is going to bring down is the small personal or single server setups used by small biz. any type of clustered hosting or even virtual hosting - the worst case is that someone can block SSL connections to a site (unless the whole server is horridly configured - which we never ever can leave out of the equation - but even then with IIS6+ it would take effort to make your server very vulnerable to this)
On another note: Disney and Nick at Night gets better ratings than Lifetime. Discovery and SciFi gets better ratings than TruTV. CNN, The History Channel and Comedy Central get better ratings than Soap, Oxygen and the golf channel.
StatCounter's total scores for Europe put IE marketshare at 48 percent and Firefox at 38 percent.
That said, it does appear that some IE users are switching to firefox at a slow pace (2% every 1/4 year, or 8% a year). At that rate, in a year and some, firefox may overtake IE share.
First, no I was speaking of web applications, not specifically ones that use ActiveX.
Secondly, why would I raise the point? No offense, but adding cost and complexity into testing an application for the possibility that at some point down the road we might want to use a different internal browser isn't really a good idea. The fact that most of our applications are web based, does make it a lot easier to switch if we have to. Testing with firefox etc has never been a requirement, although I do. Sometimes it looks bad in firefox, but as long as it's functional, we don't typically change it. I haven't ever written an entire application as an ActiveX control, but there have been (many many years ago), where we used an activeX control for things, but it was a very small part. That part could (maybe) be rewritten to not require it, perhaps. It was cheaper and faster (many fold) to not.
One thing you learn very quickly in enterprises is that many applications are short lived. A few months, a year, sometimes two, then requirements change so much that it's scrapped. Adding cost on to projects like that would be prohibitive, and it's usually impossible to tell those that are transient and those that will form the backbone of the company.
Also I don't agree with the reason you gave. ActiveX controls that were written for IE 4.0 still work in 8.0. No security patch has ever broken any ActiveX control I've ever written, so it renders your point pretty useless. You might as well say, what if we decide to use firefox 4000 next year, and they drop support for any HTML less than 6.0. Maybe we shouldn't make web apps in case that happens and go back to distributing applications that don't rely on technologies we don't completely control. It's the only way to be sure our stuff will still run 10 years from now.
First, no I was speaking of web applications, not specifically ones that use ActiveX.
Secondly, why would I raise the point? No offense, but adding cost and complexity into testing an application for the possibility that at some point down the road we might want to use a different internal browser isn't really a good idea. The fact that most of our applications are web based, does make it a lot easier to switch if we have to. Testing with firefox etc has never been a requirement, although I do. Sometimes it looks bad in firefox, but as long as it's functional, we don't typically change it. I haven't ever written an entire application as an ActiveX control, but there have been (many many years ago), where we used an activeX control for things, but it was a very small part. That part could (maybe) be rewritten to not require it, perhaps. It was cheaper and faster (many fold) to not.
One thing you learn very quickly in enterprises is that many applications are short lived. A few months, a year, sometimes two, then requirements change so much that it's scrapped. Adding cost on to projects like that would be prohibitive, and it's usually impossible to tell those that are transient and those that will form the backbone of the company.
Actually, in every web based application I've developed, the driving reason was so to avoid the installation problems and support. It's easy to tell users to go to this or that URL to use a new application, a heck of a lot easier than rolling out apps everywhere. Independance from a specific operating system or browser has NEVER EVER come up.
Because it's trivial? I preferred it didn't ask. But that's my opinion.
Perhaps a slider with 3 setting for automatic updates: Auto install, Download but install manually, and Anal retentive future botnet. Oh wait, they have that already.
The stations could have broadcast in both digital and analog if they wanted to. They would have had to bid on the radio spectrum they wanted to use for analog service just like anyone else however.
No, but you tried turning this into something based on nationality. Why would you want to see people of any country lose jobs?
First, Red Hat employs people from many countries, but where it's headquartered is irrelevant to your argument, so why point out that it's an American company unless you are envious of something American? Then you go on to say "Swizz" might pick an European Linux distro. I wasn't aware the Linux distros had nationalities either. And then you mention America twice more, and cheer that following your logic, American jobs might be lost. You aren't happy that perhaps more European jobs may be created, just that American jobs are lost. You are obviously are a bitter, hateful person, with misdirected resentment. I pity you.
If you are referring to the name "COM", you would be correct.
COM is a name given to a set of technologies that existed prior to the name, one of which is OLE. OLE 1.0 was released in 1990 and predates SOM. So the technologies that the name COM encompasses predates SOM. I hope that makes this clearer. The API for exchanging data between applications existed prior to COBRA in OLE. COBRA based much on OLE (Now known as COM). Microsoft extended OLE to be able to talk across networks originally calling it network OLE, but later refers to this technology as DCOM or Distributed COM.
If you want to go back even further, NetDDE existed in 1988, and did much of what COBRA/DCOM did, but it was harder to use (message based rather than object like), and was finally replaced completely for the first time in Microsoft Vista. (Windows XP's Clipboard viewer, hearts game, etc still use NetDDE to talk across the network).
I apologize if using the more generic/newer name for the technologies in question has caused you to become confused. I hope I have cleared some of that up for you.
True, it was in response to great grand parent who was trying to invalidate posts on slashdot because of the credentials he listed, which is much less than many here have. I didn't go any further than I needed to invalidate his "proof".
Slashdot Mirror
I looked through the cases of the past 5 years, yes. No I didn't make a statistical analysis, it wasn't necessary as it wasn't even close. If you feel otherwise, please go ahead, but even looking at the first few pages should have given you a pretty good idea.
Cases against companies like:
Microsoft
Visa
American Express
Coca-Cola
Chrysler
Delta Airlines
Oracle
Texas Instruments
Qualcomm
Intel
Apple
Did you actually look through those cases? I doubt it, because you would find:
A) There is an unproportionally large number of cases against American companies .
B) Of the verdicts, those cases raised against American companies have an unusually higher conviction rate compared to the cases against non-American companies.
C) When an American company is found guilty, the fines are higher than those against non-American companies.
For example, the two largest fines the EC has levied, were both against American companies (Intel, Microsoft).
First, most people wouldn't be running Vista Pro, they'd be running the less expensive Vista Home. Secondly, since you can't move the OS to your next machine, it's more comparable to an OEM version of Vista Home.
Vista Home Basic OEM: $84 (newegg)
Windows 7 Home OEM (full version): $84 **Projected based on vista prices at newegg
Total: $168
Mac OS X 10.4: $129
Mac OS X 10.5: $129
Mac OS X 10.6: $29
Total: $287
That is still debated, apparently. The FSF believes as you do, while many others, including OSI say otherwise. Personally, I side with OSI's interpretation.
http://www.nusphere.com/products/library/gpl_0401openmag.pdf
the iis worker proccess when accepting a connection goes ahead and establishes a server side out bound port to talk back to the client
No, it doesn't, and it won't. Please test this yourself before coming back and arguing this again.
and yes iis will send info out one ip that was sourced on a diffrent - and it will lie about the source.. trust me if you do multi home without BGP and your up stream providers actualy check header info you will see this happen.
No, it won't. I am currently multi homed across many networks, and I tell you without a doubt that is incorrect. You are most likely confusing the difference between a network interface and an IP address.
my logic isn't flawed - it just how iis behaves - and the whole conversation on this branch is WHY apache is vulnerable and why IIS isn't (or at least not normally)
Yes, this whole conversation is why apache is vulnerable and IIS isn't, but the reasons you gave are wrong.
and as for SSL being bound to an IP your right it doesn't have to be a single ip it can be a range. BUT if you are hosting more than a single SSL site on the same server you must assign each one their own ip(s) instead of using the "any available" option under iis - which limits the number of available address and there for ports for it to source a reply from
Again, a very limited view of what happens, but mostly correct. "it can be a range" is incorrect, as you yourself say, it can be "any available", which is not a range. So you've contradicted yourself. The most common behavior is to assign each site their own IP address, but that is only so that you can use the default incoming port. You CAN assign multiple sites to the same IP address, each residing on it's own port, and things will function just fine. Unfortunately, poorly designed (likely corporate) firewalls may refuse to connect to that port, but that's another issue.
I could, but I didn't.
Many many times, actually.
Your understanding of how TCP connections work is very flawed.
well the connection limit for a single host is the number of available ports for outbound traffic (to return data to the client)
Incorrect.
by default (from memory here) i want to say IIS is set up to use ~4k ports for outbound - i do know that can be changed to allow ports 1024+ to be used meaning the number of avaliable ports would be ~64.5k
Sort of, but you are talking about the ports a client a may to establish a connection to a server. This has no use at all for a server that is already bound to a single port.
and that is per host ip - and unless you have the site bound to a specific host ip address (instead of using site headers - iis will respond on an alternate ip (if it has one) when another is out of ports (infact i think it round robbins - i can't remember)
Incorrect. If the server were to respond on a different IP (or port for that matter) than the one the client initially requested, it would be discarded.
Where this could be a problem for iis is with SSL as SSL has to be bound to an IP and the max amount of ports for that IP is going to be less than the number of ports that the client can send from. So yes this type of exploit could cause an outage in IIS - it is much less likely (based on default config) than apache - and is only realistically likely when trying to attack an SSL supporting site. (like they are hard to find)
Completely incorrect. SSL does not *HAVE TO* be bound to an IP (although it usually is). The max ports is irrelevant, it will only use one. No, IIS wouldn't be vulnerable. The rest is garbage.
About the only IIS server that this is going to bring down is the small personal or single server setups used by small biz. any type of clustered hosting or even virtual hosting - the worst case is that someone can block SSL connections to a site (unless the whole server is horridly configured - which we never ever can leave out of the equation - but even then with IIS6+ it would take effort to make your server very vulnerable to this)
Incorrect.
You were right up until you said new unique port. That is incorrect. You remain on the same port, but on a new socket.
On another note:
Disney and Nick at Night gets better ratings than Lifetime.
Discovery and SciFi gets better ratings than TruTV.
CNN, The History Channel and Comedy Central get better ratings than Soap, Oxygen and the golf channel.
I'm not sure what that means though.
Citation needed.
From your own link:
StatCounter's total scores for Europe put IE marketshare at 48 percent and Firefox at 38 percent.
That said, it does appear that some IE users are switching to firefox at a slow pace (2% every 1/4 year, or 8% a year). At that rate, in a year and some, firefox may overtake IE share.
First, no I was speaking of web applications, not specifically ones that use ActiveX.
Secondly, why would I raise the point? No offense, but adding cost and complexity into testing an application for the possibility that at some point down the road we might want to use a different internal browser isn't really a good idea. The fact that most of our applications are web based, does make it a lot easier to switch if we have to. Testing with firefox etc has never been a requirement, although I do. Sometimes it looks bad in firefox, but as long as it's functional, we don't typically change it. I haven't ever written an entire application as an ActiveX control, but there have been (many many years ago), where we used an activeX control for things, but it was a very small part. That part could (maybe) be rewritten to not require it, perhaps. It was cheaper and faster (many fold) to not.
One thing you learn very quickly in enterprises is that many applications are short lived. A few months, a year, sometimes two, then requirements change so much that it's scrapped. Adding cost on to projects like that would be prohibitive, and it's usually impossible to tell those that are transient and those that will form the backbone of the company.
Also I don't agree with the reason you gave. ActiveX controls that were written for IE 4.0 still work in 8.0. No security patch has ever broken any ActiveX control I've ever written, so it renders your point pretty useless. You might as well say, what if we decide to use firefox 4000 next year, and they drop support for any HTML less than 6.0. Maybe we shouldn't make web apps in case that happens and go back to distributing applications that don't rely on technologies we don't completely control. It's the only way to be sure our stuff will still run 10 years from now.
First, no I was speaking of web applications, not specifically ones that use ActiveX.
Secondly, why would I raise the point? No offense, but adding cost and complexity into testing an application for the possibility that at some point down the road we might want to use a different internal browser isn't really a good idea. The fact that most of our applications are web based, does make it a lot easier to switch if we have to. Testing with firefox etc has never been a requirement, although I do. Sometimes it looks bad in firefox, but as long as it's functional, we don't typically change it. I haven't ever written an entire application as an ActiveX control, but there have been (many many years ago), where we used an activeX control for things, but it was a very small part. That part could (maybe) be rewritten to not require it, perhaps. It was cheaper and faster (many fold) to not.
One thing you learn very quickly in enterprises is that many applications are short lived. A few months, a year, sometimes two, then requirements change so much that it's scrapped. Adding cost on to projects like that would be prohibitive, and it's usually impossible to tell those that are transient and those that will form the backbone of the company.
You realize that never worked very well, it isn't maintained, and only works with firefox 1.5 or lower, right?
Actually, in every web based application I've developed, the driving reason was so to avoid the installation problems and support. It's easy to tell users to go to this or that URL to use a new application, a heck of a lot easier than rolling out apps everywhere. Independance from a specific operating system or browser has NEVER EVER come up.
Because it's trivial? I preferred it didn't ask. But that's my opinion.
Perhaps a slider with 3 setting for automatic updates: Auto install, Download but install manually, and Anal retentive future botnet. Oh wait, they have that already.
The stations could have broadcast in both digital and analog if they wanted to. They would have had to bid on the radio spectrum they wanted to use for analog service just like anyone else however.
You absolutely would need an FCC license to do that.
No, but you tried turning this into something based on nationality. Why would you want to see people of any country lose jobs?
First, Red Hat employs people from many countries, but where it's headquartered is irrelevant to your argument, so why point out that it's an American company unless you are envious of something American? Then you go on to say "Swizz" might pick an European Linux distro. I wasn't aware the Linux distros had nationalities either. And then you mention America twice more, and cheer that following your logic, American jobs might be lost. You aren't happy that perhaps more European jobs may be created, just that American jobs are lost. You are obviously are a bitter, hateful person, with misdirected resentment. I pity you.
Jealous much?
If you are referring to the name "COM", you would be correct.
COM is a name given to a set of technologies that existed prior to the name, one of which is OLE. OLE 1.0 was released in 1990 and predates SOM. So the technologies that the name COM encompasses predates SOM. I hope that makes this clearer. The API for exchanging data between applications existed prior to COBRA in OLE. COBRA based much on OLE (Now known as COM). Microsoft extended OLE to be able to talk across networks originally calling it network OLE, but later refers to this technology as DCOM or Distributed COM.
If you want to go back even further, NetDDE existed in 1988, and did much of what COBRA/DCOM did, but it was harder to use (message based rather than object like), and was finally replaced completely for the first time in Microsoft Vista. (Windows XP's Clipboard viewer, hearts game, etc still use NetDDE to talk across the network).
I apologize if using the more generic/newer name for the technologies in question has caused you to become confused. I hope I have cleared some of that up for you.
Sorry, I should have been more clear.
DDE was release in 1987.
OLE which is an extension of DDE, was released in 1990. Later this will form the basis of COM, and ActiveX.
** Disclaimer: I used to work for the parent of the wonderware company discussed in the DDE wikipedia article.
COM - or OLE/DDE as it was called originally -- was released in 1990, predating CORBA.
True, it was in response to great grand parent who was trying to invalidate posts on slashdot because of the credentials he listed, which is much less than many here have. I didn't go any further than I needed to invalidate his "proof".