Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements


evildictaitor evildictait​or Devil's advocate
  • Heartbleed

    , blowdart wrote

    Then perhaps you can ask MSRC to reclassify. The maximum security impact given to bulletins is a subject of much discussion and we always choose the most serious. Building a new auth token and having code act on it isn't an RCE.

    It was RCE because with a web.config you get the machine key of the ASP.NET application. With the machine key of the ASP.NET application you can sign any data as part of the ViewState, which means that you can fabricate malicious viewstate which is then deserialized. And although it wasn't widely known at the time, the deserializer was vulnerable to RCE (CVE-2013-3171).

    So tl;dr is that the web.config oracle was RCE at the time if your web.config contained a machine key and used viewstates anywhere in your application.

    Even now it's more than an information disclosure; with the machine key you can still get an arbitrary file delete from the ASP.NET machine account (which isn't many files, but it isn't zero files either), and this bug has been around since at least 2012.

  • Things to say to Cortana

    Cortana! <beep-boop>

    I have a meeting tomorrow at 9am, but John can't make it.

    <Inspecting calendar>

    <The meeting ... tomorrow ... at nine A..M.. no longer contains anyone in your line management chain and the schedule does not contain any projects you are involved in. Would you like me to delete the invite so you can have a lie in tomorrow?>

    Thanks Cortana. That sounds great.

    <Deleting the invite and setting alarm for nine ... thirty A..M>

  • So is SQL Server 2014 in memory Hekaton gonna crush nosql?

    , RealBboy360 wrote

    I just think in the long run a database by Microsoft or oracle is going to outperform open source, even if an open source db or file system has the jump on them for a few years.

    On what planet does whether a product is open/closed have any meaningful impact on that product's performance?


  • Heartbleed

    , blowdart wrote

    That was not an RCE. That was an Information Disclosure attack. If you're going to discuss ASP.NET bugs I'd ask you get their impact right, as I'm responsible for some of that process.

    It's an RCE if it's got a machine key in it and .NET <= 4.5

  • The IPC barrier has been broken

    They will need to keep the restriction on store apps (or at least mark store apps that do this with a big banner shouting "warning!" to users), because understanding how to secure these IPC channels is depressingly hard for ordinary developers (there were several hundred bugs filed by WinSec against this type of channel before Win8 shipped) - and that's even before you realize that a malicious app-store doing this gets medium integrity impersonation of the user on the desktop for free doing this.

    Or in other words, this breaks the entire AppContainer security model by turning a download of one of these apps into effectively double-clicking an EXE you found on the Internet and hoping it doesn't pwn your system.

    Generally, a better solution for store apps would be for Windows to be a bit more proactive at inventing and shipping new WinRTs.

    For example, even on this forum some developers have asked for COM1 read/write from inside a Windows Store app. Now the correct approach to this is not for Microsoft to give developers medium integrity DLL execution. That's like your four year old daughter asking for a wendyhouse and you handing her a powerdrill and telling her she can build her own.

    The correct response is to write a bespoke COM1-over-IPC channel - Microsoft is able to build and secure these because that's what WinRTs are. Microsoft should be proactively seeking out new ideas for WinRT that developers are really asking for, and implementing them and releasing them out-of-band with the rest of the release cycle of Windows.

    Why should a developer have to wait until 2016 (or later, who knows?) before getting a feature that's make-or-break for their app? Like being able to 3D-print, or use a custom barcode scanner? Or maybe a banking app that interacts with a custom card reader or something?

    It's nice that Microsoft is allowing developers to be flexible here - but developers need to be careful. That powertool is not only heavy and complicated; it's dangerous too.

  • The story of the Windows XP background

    , itsnotabug wrote

    i wonder how much he made on the outright sale and whether it would have been better for him to get a royalty per use? i'm thinking yes :)

    Fed-Ex will refuse to carry anything with a declared value in today's money of $50,000 or above, so it's more than that, but it might not be as huge as you think.

    Regarding royalties, my guess is that Microsoft will have wanted ownership of whatever became the Windows XP background image considerably more than they wanted his photo to be that image. If he'd have held out for royalties, the Windows XP background would be something entirely different and he'd have not got anything.

  • Heartbleed

    , ScanIAm wrote

    The real bug is that a piece of security software can allocate memory that hasn't been wiped before and after use. 

    That would make no difference in this case; the bug here isn't that it's returning uninitialized memory, but that it's reading data beyond the allocation. Even zeroing mallocs would return passwords, SSL keys and SSNs if they had this bug.

  • The story of the Windows XP background

    Apparently it's a real place, north of San Francisco. And it wasn't photoshopped.

    Watch here: https://www.youtube.com/watch?v=AVXY8OEZAEQ

  • Heartbleed

    , Bass wrote

    RCE in a web server? Bleh. Web servers will be web servers. I think a lot of hysteria comes from the fact that the bug is in an SSL library, who's entire purpose to some extent is to provide security. Security hole in a security library? That's scandalous. Especially when compounded with all the latent hysteria over the months from you know what.

    RCEs in nginx and IIS would allow you to take private keys right off the server.

    So I'm not sure what your point is. If Heartbleed is bad, RCE against a default-install of a major webserver like Apache, IIS or nginx or the operating system that hosts it is just as bad, if not worse (by definition).

  • Heartbleed

    The security of a product has nothing to do with whether it is open or closed source. It has everything to do with whether you use secure programming practices when you write and test your code.

    Also heartbleed is, whilst quite serious and needing to be urgently patched, not any more or less serious than a whole ton of other bugs that come out in any given year.

    Remember the YAML deserialization bug which was RCE against a fairly large fraction of the Internet? Or the web.config padding oracle that was RCE versus most IIS installs? Or how about the MS-0867 bug, which was RCE against basically any Windows machine at the time.

    You could have used any of those bugs to take SSL private keys and userdata from a webserver, and considerably more.

    And that's before we even go into vulnerabilities that are functionally equivalent to Heartbleed, but without the same level of media-fueled hysteria - like the Debian random bug, Apple's goto fail and CVE-2011-4315 which is identical in behavior to the heartbleed vulnerability but affecting just nginx instead of all of OpenSSL.