Actually leaves bash in the dust. More consistent, more composable, more robust. Extensibility which reaches beyond creating new text-parsing or text-producing commands to allows the very same command patterns to be re-used from within program logic. My sig is a one-line (121 chars IIRC) improved slashdot reader (see if you can tell how it is improved).
It is obivous, even from reading Google's details of the allegated copying that Microsoft is copying search results.
It is only obvious if you choose to close your eyes. Go read http://searchengineland.com/bing-why-googles-wrong-in-its-accusations-63279. This is by the guy who *originally broke* the story. And he is backpedaling and having second thoughts. Google manipulated him, but now he thinks they didn't really mean to. Google engineers were just incompetent?
No, you err. Bing (via Bing toolbar) are going to get click streams. They were not indexing the results page. They monitor url parameters (among other parameters) and subsequent navigation. Hence "click stream". This makes a connection between a term (in a URL parameter) and a page. That page was chosen by a *user*, not by parsing the Google results page. This is what toolbars do, Bing, Google etc. are all doing it for all sites. Bing has simply not made an exception for Google.
I know this is/., but seriously your comment is clueless. This is not what happened at all.
You can read a good follow-up by the guy who broke the story initially: http://searchengineland.com/bing-why-googles-wrong-in-its-accusations-63279. This guy has second-thoughts and several goof insights. Basically what this boils down to is Google engineers being incompetent in their analysis and blinded by their beliefs that their work was being stolen.
Except, it all they were doing is what you say, the "Bing Sting" would not have worked. They have to be doing more than simply monitoring what people click on. No amount of click analysis would cause pages THAT DON'T CONTAIN THOSE TERMS AND ARE NEVER LINKED TO BY ANYTHING CONTAINING THOSE TERMS to rise to the top of anyone's search results for those terms. Google did not insert search results that returns an "unlikely" match, they returned an impossible match.
Erhm. Google search terms are available in the URL of the results page. Bing toolbar sees page 1 with a number of words in the URL. Bing toolbar sees that user quickly navigates to another page, page2. Bing analyzer infers a (very weak) relation between terms from page 1 to page 2.
Not impossible at all. In fact, very, very probable.
The problem, of course, being copyright, and claiming work as their own. Google create a false entry, accessible only through their own site.
Bzzzzzt. Wrong. They created a public "honeypot" page available to everyone. Then they created a bogus search term and manipulated their own system to list the honeypot page for that search term. *Then* they volunteered into Bing toolbar and Suggested Sites, searched for the term and clicked the link.
Bing toolbar - doing what "toolbars" do - reported back the clickstream. The search term appears readily available in the url of the first page, and the user quickly clicks on a link on that page. Bing's feedback analyzer creates a (very weak) relation between search terms from url of page 1 to page 2. What google did was game this system so that there were no other signals. Consequently it received relatively more weight. But it is not like Bind crawled Google or anything like that, which Google would like everyone to believe.
Problem is that the way google works, the search term is readily available in the url. With Bing toolbar the user has given *his* permission for Bing to analyze the clickstream.
Some words appear in the url of what appears to be a navigational style page and a link is followed ==> Bing builds a (very weak) relation, but obviously piggybacking (with the implied permission of the user) on the judgement of the user.
Note, this is not just for Google pages, but for *any* page. And what is relayed back is not the Google results page (multiple links), but rather the much more valuable user action (a single link).
This is not Bing looking in form fields. When you do as Google does (HTTP GET) the form fields end up in the url. And the url is fair game..
This is not Bing copying Google results. This is Bing building (weak) relations based on volunteer feedback through the Bing toolbar. Just as Google does with Google toolbar.
How would a "security researcher" know that a SQL injection bug was being actively exploited if he just uncovered the bug himself?
This sounds a bit odd as using a SQL injection to expose the users' details would require you to deliberately manipulate querystring parameters or form fields. The results will display in your own browser. How would he know whether anyone else were doing this? Was it because he really didn't uncover it himself but found the 30.000 users' details somewhere else?
No, this sounds a lot more like someone mildly proficient (you can use automated tools to find SQL injections so this is just one level above script kiddie) found a bug and wanted to capitalize on it. To underline the seriousness he embellished a little on the "being actively exploited".
I take it that POF has server logs and that they can tell from those whether anyone else exploited the bug.
Wait a minute... Microsoft says the boy cheated, mother objects, everyone is outraged, Microsoft sends a Twitter message "he did cheat, we checked", and everyone says "O, that's OK then, carry on". I must be in a parallel universe.
Microsoft did check and this was not a case about a gamer being "too good" as initially claimed by mum. The kid had someone else help him edit a saved game to obtain a number of achievements. Microsoft correctly states that gaining achievements while offline is impossible and conclusive evidence of tampering.
Mother has admitted that the kid wanted that armor so bad that she actually paid someone to help them get it (by cheating). She assures us that she and her kid meant no harm. Microsoft stands firm and says they have to protect everybody else against cheaters (even if they are autistic cheaters). MS have given the kid one month XBox Live free-of-charge to play up another character, though.
Will that be good enough for you? Follow the original link. The story has been updated. Microsoft has provided info to the mother and because of the publicity has also seen it necessary to go public with the info.
Basically the kid got help (or so they claim) from somebody else who offered to outfit his character with a special armor. This helpful guy modified the profile. MS anti-cheat scanning tripped on this. Apparently the profile was updated with several achievements while offline. That is impossible, not because of lack of skills, but because those achievements are earned while *online*.
What the mother says now is that, "yes he cheated but he didn't mean no harm". MS says "he cheated; we have an obligation to other players to prevent cheating and that's what we did. We stand by that". MS will not remove the "cheater" tag, but has given the kid one month free XBox Live to play up another character.
Hum - you do realize that already at this stage, IE is the browser with the most complete implementation of HTML5 and CSS3 right?
MS has actually contributed *most* of the compliance tests (the official ones, not ACIDs) and have disclosed where IE doesn't *yet* pass the tests. You can run those test yourself and see if your favorite browser passes *all* of them (or even more than IE): http://samples.msdn.microsoft.com/ietestcenter/#html5Canvas
I'm posting this using Chrome and that chart seems to be about right, i.e. only a few of the failed tests have been corrected even though this is Chrome 8.0.552.215 and the chart is from the Chrome 7 days.
globalCompositeOperation "destination-over" is shown as "fail" for IE. If you look at the chart - and do not cherry pick like the original poster did - you will soon realize that IE is indeed the browser which is *most* compliant with the *draft* spec.
What we have here is a biased author who cannot even hide his bias, cherry picking a few areas where IE fails and trying to blow them up as all-important and outright reason to reject IE and MSs efforts. And then he goes posting it on slashdot in order to instigate a good MS bash fest. Real class.
the organizations surveyed were picked by the Linux Foundation End User Council
Next up: 10 out of 10 randomly selected stock brokers want more deregulation of the financial system 10 out of 10 randomly selected Taliban fighters don't trust the USA
You are wrong. This vulnerability is actually an artifact of the underlying encryption algorithm, and as such other products are also vulnerable, e.g. JSF (for which attacks were demonstrated before the ASP.NET one) and Ruby-on-Rails. It allows you to retrieve the full key. And the key is symmetrix, meaning that you can both decrypt and encrypt.
The attacker can gradually learn the exact machine key by manipulating something he knows to be encrypted. By padding the encrypted text from the end, and watching to see whether the server decryption fails or he hits something which *can* actually decrypt (but which may causes the app to fail), he can learn something about the key. Presumably this is because he knows that the last part of the key is used to encrypt the last part of the text.
Anything encrypted will do. Even the timing of the failure may offer the attacker valuable information, e.g. failure to decrypt results in faster fails than the application trying to run with something which actually decrypted without error only to fail a little later.
This is not specific to ASP.NET. But ASP.NET happens to use the machine key to encrypt authentication tickets. If you learn the machine key then you can fake any identity.
As this is a standard algorithm, expect the ASP.NET fix to be a sanity check (hash/signature) on the entire ciphertext so that it can reject it up front before even attempting to decrypt. Ruby-on-Rails has a similar method where you must explicitly request verify and decrypt instead of just decrypt.
Even with automatic updates fully on, you have always had to specifically choose to upgrade IE. Yes, it will show up in the "optional updates" list - but it was never checked by default. Expect the same for IE9. It's not like Chrome which silently updates - no questions asked.
(disclaimer: I use Chrome and I am quite happy with it. But I do understand how silently updating software will give some admins pause).
But of all of the platforms vulnerable to this kind of attack, in ASP.NET it is worse because once the machine key is deduced, a special request to the server using that key can be used to download any file within the application directory, such as the web.config file, which could contain sensitive information like database connection strings and passwords.
However, this is not correct. There is no key which will let you bypass the IIS/ASP.NET mappings. A number of files and file types are always configured so that they will be served by the special "prohibited" handler. An IIS/ASP.NET server will *never* (barring any bugs) serve the clean text version of web.config, *.aspx or similar files. Not with any key.
This is an attack on the authentication ticket - which is the cookie on the client which holds information about your login, expiry etc. This is separate from the session cookie. The authentication ticket comes into play when you use forms authentication. Note - this is an alternative to Windows authentication. Forms authentication is typically used for public facing websites. When you run FA you are not a Windows user on the server. So this attack does *not* allow you to run as "root" (the Local System) user.
It *is* a serious attack as it allows you to impersonate anyone provided you know their user name. But it is not a server compromise. Of course, if the application so designed so that one or more of the users you can impersonate are application administrators you can do what they do.
Note to everyone: IIS is *not* running under the Local System account. By default it is running as Network Service. This is a regular user account (on the local machine) with the added permission to represent the machine on the network. This means that if some other machine explicitly allows WebServerName$ access to resources, the IIS service can access those remote resources with those rights. This is the default, but in professional environments it is common to configure separate application pools so that each app runs under its own user account. Still, these accounts require no special privileges.
Which account the IIS service is running under is irrelevant in the context of the current vulnerability, as it does not allow you to run code on the server. It only allows you to impersonate users.
.NET is actually a security success-story. Compared to similar (i.e. Java),.NET has experienced almost an order of magnitude fewer vulnerabilities, especially if you consider the severity of the vulns.
SteadyState makes a virtual harddisk. In essense it is itself a "rootkit" in that uses copy-on-write at reads/writes the changed block from/to a log file. When rebooting it simply deletes the logfile and the disk is back to the original state. I would like to see the rootkit which can survive that...
As explained in many places on the web, this "Microsoft will not sue you" is very different from actually granting a license.
I see. If you read it on the Internet then it absolutely must be true.
For example, Microsoft could sell off one of the relevant patents to a proxy agent, which would then sue anyone and everyone (but Microsoft).
You are just forgetting a small detail. And so is your Internet groklaw echo-chamber: Selling off a patent does not absolve the buyer from the licenses granted for the patent.
Ah - but "promise not to sue" is not a patent grant even if it is legally binding, you say. Perhaps the law is such that those obligations are not transferred with the patent?
Perhaps so - even though I doubt it. But you see, the detail which is conveniently overlooked by the Internet echo-chamber is that a patent grant has already been issued. This latest community promise was in response to fear that Microsoft would just sue anyway and that open source projects would not have the financial strength to fight it. This community promise will ensure a speedy dismissal of any lawsuit.
As part of the standardization process Microsoft "will grant, on a non-discriminatory basis, to any party requesting it, licenses on commercially reasonable terms and conditions, for it's patents, if any, deemed to be necessary for the implementation of the Ecma standard".
Ah, see that commercially in there? Wiggle room! Sorry - nope. Microsoft has already granted such patents for Novell free of charge. Meaning that charging anyone else license fees would be discriminatory - which they are now estopped from.
These grant obligations *will* transfer to anyone else who might acquire the patents.
Even so, if you believe this risk exists, it follows that it is not just Microsoft patents which come with this risk? Who is to say that IBM will not sell of their patents? Or Oracle will sell of patents to someone who will sue all Java implementations. Your speculations amount to nothing more than FUD. The very definition of FUD. You set aside all facts to reach a predetermined conclusion: That.NET *is* a trap!
So you are suggesting I can freeze IO to the machine, then run a snapshot command on NTFS?
I would be glad to hear it.
The Volume Shadow Service (VSS) is always running (by default). Backup utilities - including the ones which come with Windows - use VSS to create a snapshot and perform backup from that point in time. It doesn't freeze IO; rather it goes to copy-on-write.
On server versions you can also create snapshots interactively by using the vssadmin tool.
Shares can be set up to create a shadow copies multiple times per day. This is not copy on every write - but it *is* copy on write once a block is part of a snapshot. Any client (plugin needed for XP, IIRC) can display previous versions which are available snapshots.
VSS actually goes beyond NTFS integration (which is probably why it is a service and not just a NTFS feature). Certain applications - e.g. Exchange, SQL Server and Hyper-V - also integrate with VSS. Instead of VSS operating directly on e.g. SQL Server files, it integrates with the server to create a snapshot for the database files. During restore the system knows how some applications took part in the shadow copy. This ensures that I can correctly restore *all* the files needed to bring a SQL server database back to a certain point-in-time. It also allows the SQL server to prune the log automatically.
I have a Server2008R2 which has several Hyper-V images (development and testing). When I perform a backup of the server, VSS interacts with Hyper-V to perform backup of the virtual machines as well. A Server2003 which hasn't been set up to support VSS is actually "hibernated" by Hyper-V/VSS - then backed up - then brought back into running state. That could be considered "freezing IO", I suppose.
It's not really a multi-language platform. It's a programming language that tries to do everything, and a mapping from all the languages out there to that language.
Come again? What exactly makes a platform then?
You are correct that.NET is based on a single basic language which every other language must "map" to. By convention we don't refer to this as "mapping" but rather as compilation.
Compilation takes some higher-order language and compiled to a basic language. In this case the basic language is called Common Intermediate Language (CIL). No, it is not C#.
You may not know this, but CIL actually is (and always was) "bigger" than C# in that it has features still not exposed through C#. Examples are indexed properties (C# only has simple properties which may be of an indexed type - not the same) and non-zero based arrays. C# is but one language which "maps" to this language. This is actually quite a bit different compared to the Java platform, which doesn't even have unsigned integers or custom value types because they are not in Java. It is only now (planned for JDK7) that the Java platform may actually see features *not* exposed through Java.
It does not, however, answer what happens if the patents change hands either through bankruptcy or sale. In Sun's case they sold their patents along with the company. To be fair, there was never an explicit legal promise they wouldn't use them.
IANAL and I'm not intimately familiar with US patent law, *but* it appears to me that any buyer of a patent (whether it be an outright sale or a bankruptcy) would have to accept any grants, agreements and licenses already made for that patent by the seller.
License agreements aren't revoked just because the licensed part changes owner. The new owner will have to honor any agreement affecting the part, and the fact should be reflected in the price/value of transaction. If I buy a patent from someone who has irrevocably licensed it to a certain customer (or everyone) I will have to respect that agreement.
Now, perhaps this community promise isn't the same thing as a patent grant. It appears more to be a waiver (estoppel) of rights to sue. Whether this is some sinister loophole I really can say. But I would expect that it has the same validity as an outright patent grant.
Re: Suns promise on Java: They actually did make such a promise/grant. Only, it came with some (a lot) of preconditions which Google does not meet in this case: The patent grants only covered a full implementation of Java SE *and* only if had also been certified by Sun (i.e. Harmony is also in danger here). Google's Dalvik is not an implementation of Java SE.
I see your point about patents and the legal system. It really doesn't matter if you are right or wrong, all that matters is whether you can convince a jury. Most software patents are overly broad and/or too obvious, at least to people in the industry. But I still fail to see how this makes.NET/Mono more dangerous than other software. If anything, Mono has patent coverage from at least one of the big patent holders in the industry.
Well... to be fair, there is a difference between Oracle suing the GOOGLE company and Microsoft promising not to sue YOU (user/developer) for using the Mono implementation... mainly because Novell/Microsoft relation.
I wonder how far would Microsoft allow Google to go in implementing a C# compiler/interpreter in the same way they are doing it with java...
Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation, to the extent it conforms to one of the Covered Specifications, and is compliant with all of the required parts of the mandatory provisions of that specification ("Covered Implementation")
Covered specifications (extract):
C# Language Specification - Ecma-334, 4th Edition and ISO/IEC 23270:2006
Common Language Infrastructure (CLI) - Ecma-335, 4th Edition and ISO/IEC 23271:2006
(Note: This has nothing to do with Novell. You may be thinking of the Silverlight/Moonlight partnership where Microsoft has made a similar promise not to sue Novell or any of their customers or contributors for implementing Moonlight. Moonlight does not compare to Dalvik. C# and CLR/CTS does).
So, Microsoft has forever waived their right to sue for infringement of (Microsoft) patents which are necessary for implementing the specifications. Does that answer your question?
Slashdot Mirror
someNullableInt ?? 0
TFA is a little thin - it is basically a slideshow.
Still, IE9 beats out Chrome 10 in webkits own sunspider benchmark. On my old rig:
IE9: 348.2ms +/- 0.8%
Chrome: 446.0ms +/- 1.9%
Actually leaves bash in the dust. More consistent, more composable, more robust. Extensibility which reaches beyond creating new text-parsing or text-producing commands to allows the very same command patterns to be re-used from within program logic. My sig is a one-line (121 chars IIRC) improved slashdot reader (see if you can tell how it is improved).
It is obivous, even from reading Google's details of the allegated copying that Microsoft is copying search results.
It is only obvious if you choose to close your eyes. Go read http://searchengineland.com/bing-why-googles-wrong-in-its-accusations-63279. This is by the guy who *originally broke* the story. And he is backpedaling and having second thoughts. Google manipulated him, but now he thinks they didn't really mean to. Google engineers were just incompetent?
They are going to get search results.
No, you err. Bing (via Bing toolbar) are going to get click streams. They were not indexing the results page. They monitor url parameters (among other parameters) and subsequent navigation. Hence "click stream". This makes a connection between a term (in a URL parameter) and a page. That page was chosen by a *user*, not by parsing the Google results page. This is what toolbars do, Bing, Google etc. are all doing it for all sites. Bing has simply not made an exception for Google.
I know this is /., but seriously your comment is clueless. This is not what happened at all.
You can read a good follow-up by the guy who broke the story initially: http://searchengineland.com/bing-why-googles-wrong-in-its-accusations-63279. This guy has second-thoughts and several goof insights. Basically what this boils down to is Google engineers being incompetent in their analysis and blinded by their beliefs that their work was being stolen.
Except, it all they were doing is what you say, the "Bing Sting" would not have worked. They have to be doing more than simply monitoring what people click on. No amount of click analysis would cause pages THAT DON'T CONTAIN THOSE TERMS AND ARE NEVER LINKED TO BY ANYTHING CONTAINING THOSE TERMS to rise to the top of anyone's search results for those terms. Google did not insert search results that returns an "unlikely" match, they returned an impossible match.
Erhm. Google search terms are available in the URL of the results page. Bing toolbar sees page 1 with a number of words in the URL. Bing toolbar sees that user quickly navigates to another page, page2. Bing analyzer infers a (very weak) relation between terms from page 1 to page 2.
Not impossible at all. In fact, very, very probable.
The problem, of course, being copyright, and claiming work as their own.
Google create a false entry, accessible only through their own site.
Bzzzzzt. Wrong. They created a public "honeypot" page available to everyone. Then they created a bogus search term and manipulated their own system to list the honeypot page for that search term. *Then* they volunteered into Bing toolbar and Suggested Sites, searched for the term and clicked the link.
Bing toolbar - doing what "toolbars" do - reported back the clickstream. The search term appears readily available in the url of the first page, and the user quickly clicks on a link on that page. Bing's feedback analyzer creates a (very weak) relation between search terms from url of page 1 to page 2. What google did was game this system so that there were no other signals. Consequently it received relatively more weight. But it is not like Bind crawled Google or anything like that, which Google would like everyone to believe.
Problem is that the way google works, the search term is readily available in the url. With Bing toolbar the user has given *his* permission for Bing to analyze the clickstream.
Some words appear in the url of what appears to be a navigational style page and a link is followed ==> Bing builds a (very weak) relation, but obviously piggybacking (with the implied permission of the user) on the judgement of the user.
Note, this is not just for Google pages, but for *any* page. And what is relayed back is not the Google results page (multiple links), but rather the much more valuable user action (a single link).
This is not Bing looking in form fields. When you do as Google does (HTTP GET) the form fields end up in the url. And the url is fair game..
This is not Bing copying Google results. This is Bing building (weak) relations based on volunteer feedback through the Bing toolbar. Just as Google does with Google toolbar.
How would a "security researcher" know that a SQL injection bug was being actively exploited if he just uncovered the bug himself?
This sounds a bit odd as using a SQL injection to expose the users' details would require you to deliberately manipulate querystring parameters or form fields. The results will display in your own browser. How would he know whether anyone else were doing this? Was it because he really didn't uncover it himself but found the 30.000 users' details somewhere else?
No, this sounds a lot more like someone mildly proficient (you can use automated tools to find SQL injections so this is just one level above script kiddie) found a bug and wanted to capitalize on it. To underline the seriousness he embellished a little on the "being actively exploited".
I take it that POF has server logs and that they can tell from those whether anyone else exploited the bug.
Wait a minute... Microsoft says the boy cheated, mother objects, everyone is outraged, Microsoft sends a Twitter message "he did cheat, we checked", and everyone says "O, that's OK then, carry on". I must be in a parallel universe.
Microsoft did check and this was not a case about a gamer being "too good" as initially claimed by mum. The kid had someone else help him edit a saved game to obtain a number of achievements. Microsoft correctly states that gaining achievements while offline is impossible and conclusive evidence of tampering.
Mother has admitted that the kid wanted that armor so bad that she actually paid someone to help them get it (by cheating). She assures us that she and her kid meant no harm. Microsoft stands firm and says they have to protect everybody else against cheaters (even if they are autistic cheaters). MS have given the kid one month XBox Live free-of-charge to play up another character, though.
Will that be good enough for you? Follow the original link. The story has been updated. Microsoft has provided info to the mother and because of the publicity has also seen it necessary to go public with the info.
Basically the kid got help (or so they claim) from somebody else who offered to outfit his character with a special armor. This helpful guy modified the profile. MS anti-cheat scanning tripped on this. Apparently the profile was updated with several achievements while offline. That is impossible, not because of lack of skills, but because those achievements are earned while *online*.
What the mother says now is that, "yes he cheated but he didn't mean no harm". MS says "he cheated; we have an obligation to other players to prevent cheating and that's what we did. We stand by that". MS will not remove the "cheater" tag, but has given the kid one month free XBox Live to play up another character.
Hum - you do realize that already at this stage, IE is the browser with the most complete implementation of HTML5 and CSS3 right?
MS has actually contributed *most* of the compliance tests (the official ones, not ACIDs) and have disclosed where IE doesn't *yet* pass the tests. You can run those test yourself and see if your favorite browser passes *all* of them (or even more than IE): http://samples.msdn.microsoft.com/ietestcenter/#html5Canvas
I'm posting this using Chrome and that chart seems to be about right, i.e. only a few of the failed tests have been corrected even though this is Chrome 8.0.552.215 and the chart is from the Chrome 7 days.
globalCompositeOperation "destination-over" is shown as "fail" for IE. If you look at the chart - and do not cherry pick like the original poster did - you will soon realize that IE is indeed the browser which is *most* compliant with the *draft* spec.
What we have here is a biased author who cannot even hide his bias, cherry picking a few areas where IE fails and trying to blow them up as all-important and outright reason to reject IE and MSs efforts. And then he goes posting it on slashdot in order to instigate a good MS bash fest. Real class.
The best way to avoid hitting yourself in the head with a hammer is by not picking up the hammer in the first place.
Right. It is much better to ram in the nails with your forehead instead.
Who was surveyed?
from the TFA:
the organizations surveyed were picked by the Linux Foundation End User Council
Next up:
10 out of 10 randomly selected stock brokers want more deregulation of the financial system
10 out of 10 randomly selected Taliban fighters don't trust the USA
Some other rather solid MS products (if a little developer oriented):
You are wrong. This vulnerability is actually an artifact of the underlying encryption algorithm, and as such other products are also vulnerable, e.g. JSF (for which attacks were demonstrated before the ASP.NET one) and Ruby-on-Rails. It allows you to retrieve the full key. And the key is symmetrix, meaning that you can both decrypt and encrypt.
The attacker can gradually learn the exact machine key by manipulating something he knows to be encrypted. By padding the encrypted text from the end, and watching to see whether the server decryption fails or he hits something which *can* actually decrypt (but which may causes the app to fail), he can learn something about the key. Presumably this is because he knows that the last part of the key is used to encrypt the last part of the text.
Anything encrypted will do. Even the timing of the failure may offer the attacker valuable information, e.g. failure to decrypt results in faster fails than the application trying to run with something which actually decrypted without error only to fail a little later.
This is not specific to ASP.NET. But ASP.NET happens to use the machine key to encrypt authentication tickets. If you learn the machine key then you can fake any identity.
As this is a standard algorithm, expect the ASP.NET fix to be a sanity check (hash/signature) on the entire ciphertext so that it can reject it up front before even attempting to decrypt. Ruby-on-Rails has a similar method where you must explicitly request verify and decrypt instead of just decrypt.
Even with automatic updates fully on, you have always had to specifically choose to upgrade IE. Yes, it will show up in the "optional updates" list - but it was never checked by default. Expect the same for IE9. It's not like Chrome which silently updates - no questions asked.
(disclaimer: I use Chrome and I am quite happy with it. But I do understand how silently updating software will give some admins pause).
Thank you for an informative post!
But of all of the platforms vulnerable to this kind of attack, in ASP.NET it is worse because once the machine key is deduced, a special request to the server using that key can be used to download any file within the application directory, such as the web.config file, which could contain sensitive information like database connection strings and passwords.
However, this is not correct. There is no key which will let you bypass the IIS/ASP.NET mappings. A number of files and file types are always configured so that they will be served by the special "prohibited" handler. An IIS/ASP.NET server will *never* (barring any bugs) serve the clean text version of web.config, *.aspx or similar files. Not with any key.
This is an attack on the authentication ticket - which is the cookie on the client which holds information about your login, expiry etc. This is separate from the session cookie. The authentication ticket comes into play when you use forms authentication. Note - this is an alternative to Windows authentication. Forms authentication is typically used for public facing websites. When you run FA you are not a Windows user on the server. So this attack does *not* allow you to run as "root" (the Local System) user.
It *is* a serious attack as it allows you to impersonate anyone provided you know their user name. But it is not a server compromise. Of course, if the application so designed so that one or more of the users you can impersonate are application administrators you can do what they do.
Note to everyone: IIS is *not* running under the Local System account. By default it is running as Network Service. This is a regular user account (on the local machine) with the added permission to represent the machine on the network. This means that if some other machine explicitly allows WebServerName$ access to resources, the IIS service can access those remote resources with those rights. This is the default, but in professional environments it is common to configure separate application pools so that each app runs under its own user account. Still, these accounts require no special privileges.
Which account the IIS service is running under is irrelevant in the context of the current vulnerability, as it does not allow you to run code on the server. It only allows you to impersonate users.
and nor about SteadyState.
.NET is actually a security success-story. Compared to similar (i.e. Java), .NET has experienced almost an order of magnitude fewer vulnerabilities, especially if you consider the severity of the vulns.
.NET (using 2.0): http://secunia.com/advisories/product/6456/
Java (JRE 1.5 which is contemporary): http://secunia.com/advisories/product/4228/
------
SteadyState makes a virtual harddisk. In essense it is itself a "rootkit" in that uses copy-on-write at reads/writes the changed block from/to a log file. When rebooting it simply deletes the logfile and the disk is back to the original state. I would like to see the rootkit which can survive that...
As explained in many places on the web, this "Microsoft will not sue you" is very different from actually granting a license.
I see. If you read it on the Internet then it absolutely must be true.
For example, Microsoft could sell off one of the relevant patents to a proxy agent, which would then sue anyone and everyone (but Microsoft).
You are just forgetting a small detail. And so is your Internet groklaw echo-chamber: Selling off a patent does not absolve the buyer from the licenses granted for the patent.
Ah - but "promise not to sue" is not a patent grant even if it is legally binding, you say. Perhaps the law is such that those obligations are not transferred with the patent?
Perhaps so - even though I doubt it. But you see, the detail which is conveniently overlooked by the Internet echo-chamber is that a patent grant has already been issued. This latest community promise was in response to fear that Microsoft would just sue anyway and that open source projects would not have the financial strength to fight it. This community promise will ensure a speedy dismissal of any lawsuit.
As part of the standardization process Microsoft "will grant, on a non-discriminatory basis, to any party requesting it, licenses on commercially reasonable terms and conditions, for it's patents, if any, deemed to be necessary for the implementation of the Ecma standard".
Ah, see that commercially in there? Wiggle room! Sorry - nope. Microsoft has already granted such patents for Novell free of charge. Meaning that charging anyone else license fees would be discriminatory - which they are now estopped from.
These grant obligations *will* transfer to anyone else who might acquire the patents.
Even so, if you believe this risk exists, it follows that it is not just Microsoft patents which come with this risk? Who is to say that IBM will not sell of their patents? Or Oracle will sell of patents to someone who will sue all Java implementations. Your speculations amount to nothing more than FUD. The very definition of FUD. You set aside all facts to reach a predetermined conclusion: That .NET *is* a trap!
So you are suggesting I can freeze IO to the machine, then run a snapshot command on NTFS?
I would be glad to hear it.
The Volume Shadow Service (VSS) is always running (by default). Backup utilities - including the ones which come with Windows - use VSS to create a snapshot and perform backup from that point in time. It doesn't freeze IO; rather it goes to copy-on-write.
On server versions you can also create snapshots interactively by using the vssadmin tool.
Shares can be set up to create a shadow copies multiple times per day. This is not copy on every write - but it *is* copy on write once a block is part of a snapshot. Any client (plugin needed for XP, IIRC) can display previous versions which are available snapshots.
VSS actually goes beyond NTFS integration (which is probably why it is a service and not just a NTFS feature). Certain applications - e.g. Exchange, SQL Server and Hyper-V - also integrate with VSS. Instead of VSS operating directly on e.g. SQL Server files, it integrates with the server to create a snapshot for the database files. During restore the system knows how some applications took part in the shadow copy. This ensures that I can correctly restore *all* the files needed to bring a SQL server database back to a certain point-in-time. It also allows the SQL server to prune the log automatically.
I have a Server2008R2 which has several Hyper-V images (development and testing). When I perform a backup of the server, VSS interacts with Hyper-V to perform backup of the virtual machines as well. A Server2003 which hasn't been set up to support VSS is actually "hibernated" by Hyper-V/VSS - then backed up - then brought back into running state. That could be considered "freezing IO", I suppose.
It's not really a multi-language platform. It's a programming language that tries to do everything, and a mapping from all the languages out there to that language.
Come again? What exactly makes a platform then?
You are correct that .NET is based on a single basic language which every other language must "map" to. By convention we don't refer to this as "mapping" but rather as compilation.
Compilation takes some higher-order language and compiled to a basic language. In this case the basic language is called Common Intermediate Language (CIL). No, it is not C#.
You may not know this, but CIL actually is (and always was) "bigger" than C# in that it has features still not exposed through C#. Examples are indexed properties (C# only has simple properties which may be of an indexed type - not the same) and non-zero based arrays. C# is but one language which "maps" to this language. This is actually quite a bit different compared to the Java platform, which doesn't even have unsigned integers or custom value types because they are not in Java. It is only now (planned for JDK7) that the Java platform may actually see features *not* exposed through Java.
It does not, however, answer what happens if the patents change hands either through bankruptcy or sale. In Sun's case they sold their patents along with the company. To be fair, there was never an explicit legal promise they wouldn't use them.
IANAL and I'm not intimately familiar with US patent law, *but* it appears to me that any buyer of a patent (whether it be an outright sale or a bankruptcy) would have to accept any grants, agreements and licenses already made for that patent by the seller.
License agreements aren't revoked just because the licensed part changes owner. The new owner will have to honor any agreement affecting the part, and the fact should be reflected in the price/value of transaction. If I buy a patent from someone who has irrevocably licensed it to a certain customer (or everyone) I will have to respect that agreement.
Now, perhaps this community promise isn't the same thing as a patent grant. It appears more to be a waiver (estoppel) of rights to sue. Whether this is some sinister loophole I really can say. But I would expect that it has the same validity as an outright patent grant.
Re: Suns promise on Java: They actually did make such a promise/grant. Only, it came with some (a lot) of preconditions which Google does not meet in this case: The patent grants only covered a full implementation of Java SE *and* only if had also been certified by Sun (i.e. Harmony is also in danger here). Google's Dalvik is not an implementation of Java SE.
I see your point about patents and the legal system. It really doesn't matter if you are right or wrong, all that matters is whether you can convince a jury. Most software patents are overly broad and/or too obvious, at least to people in the industry. But I still fail to see how this makes .NET/Mono more dangerous than other software. If anything, Mono has patent coverage from at least one of the big patent holders in the industry.
Well... to be fair, there is a difference between Oracle suing the GOOGLE company and Microsoft promising not to sue YOU (user/developer) for using the Mono implementation... mainly because Novell/Microsoft relation.
I wonder how far would Microsoft allow Google to go in implementing a C# compiler/interpreter in the same way they are doing it with java...
Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you for making, using, selling, offering for sale, importing or distributing any implementation, to the extent it conforms to one of the Covered Specifications, and is compliant with all of the required parts of the mandatory provisions of that specification ("Covered Implementation")
Covered specifications (extract):
(Note: This has nothing to do with Novell. You may be thinking of the Silverlight/Moonlight partnership where Microsoft has made a similar promise not to sue Novell or any of their customers or contributors for implementing Moonlight. Moonlight does not compare to Dalvik. C# and CLR/CTS does).
So, Microsoft has forever waived their right to sue for infringement of (Microsoft) patents which are necessary for implementing the specifications. Does that answer your question?