32TB of Windows 10 internal builds, core source code leak online(theregister.co.uk) |
32TB of Windows 10 internal builds, core source code leak online(theregister.co.uk) |
So far I haven't seen any links to source code.
Quote from one of the admins:
> Yes I have no idea where they got the 32TB stuff. We had a big leak of Win10 builds yes, but these were all Windows Insider stuff that were collected over time available to all Windows Insider members at one time or another.
Edit: BA's official statement: https://www.betaarchive.com/forum/viewtopic.php?f=1&t=37283
We've updated the story to explain why things aren't what they seem. Essentially, the files at the heart of the matter were there (we screenshotted them and saved copies of the forum posts) at time of writing, and they were removed later on Friday.
In terms of the 32TB: that's the full decompressed dump of Windows files uploaded to BA. From what I understand, Microsoft hasn't released 32TB of public Insider material, so obviously there's extra sauce in the mix.
That includes, yes, copies of officially released Insider builds plus confidential private stuff that should never have left Microsoft, let alone turned up in BA. We make this clear in the story - I'm starting to feel the headline could have been better to make this clearer rather than grabbing the biggest figure. I am beginning to regret this.
BA can twist and complain all it likes - but stuff that was confidential within Microsoft ended up in their FTP archive (and some is still in there, such as the ARM64 stuff). The next stage of this story will be to uncover how exactly did this material escape Redmond.
C.
Debugging symbols for most of those builds are available on symsrv.
The Windows Mobile Adaption kit (like the OEM Preinstallation Kits, OEM Adaptation Kits) is shared with a similarly sized audience, which used to include self-attested Microsoft Partners. Again, not confidential. Just gated stuff.
The Shared Source stuff is a slight unknown here because it's not clear what was in the ZIP. I presume this was a sampling of materials shared via the Shared Source Initiative (https://www.microsoft.com/en-us/sharedsource/), none of which includes high-value intellectual property, cryptographic code, third-party code, etc. It could still be damaging but Microsoft has clearly calculated the risk here; this stuff is shared with mere community MVPs.
So with all this knowledge, it's hard to digest the "omg more exploits coming" and "Microsoft lost 32TB of private IP" angles in The Register write up. I don't think there's a story here, frankly.
Do you consider windows installation images to be "compressed files" in this context?
They call it their Shared Source Initiative. They want a reason for sharing it with you but I have used, 'I am just curious.' With that excuse, this was a long time ago when I still used Windows, I got the specific code I wanted for Outlook Express.
I "resolved" the issue by dual booting. The second os(prev ubuntu, going to deb) changes something that takes away win ability to automagicly turn on my machine for updates.
The only thing this really gains anyone is it possible some non-public debug symbols might have been left in some builds. Not earth shattering.
Ehh, Panic software had a good post-mortem talking about this potentially happening to them https://panic.com/blog/stolen-source-code/
My favorite takeaway was, "With every day that passes, that stolen source code is more and more out-of-date."
I remember hearing Windows source code leaks in the past (I see articles from 2000 and 2004) and remember hearing about problems with "clean room" implementations of open source SMB implementations.
Yeah, the fundamentals and much of the source code will probably stick around for many, many years. But this has happened before and I don't see why this is any more of a big deal.
Dead man's switch?
At this point avoiding links is pointless as the source code will be essentially public knowledge in matter of days/weeks. Damage control is the only strategy left. The sooner security researchers outside Microsoft can start analyzing and reporting vulnerabilities, the better.
He never actually stated he wanted it for security, just left it easy to imply.
I wonder if that could be used to narrow down who pulled the code during that window.
What were you implying?
2. If microsoft sued wine devs it would be horrible for Microsofts public image. They won't do it.
3. I hope the WINE devs don't listen to you.
This might be a boon for the ReactOS folks, who are trying to implement the NT kernel, except for seeing the Windows source code automatically disqualifies you from being a contributor.
If anything, this could make their legal situation more sticky.
IIRC, they had to go through some trouble to find people for that rewrite who had not looked at Microsoft's source code AND the parts of the Wine/ReactOS source code that needed to be rewritten.
So I am convinced that they will make extra sure not to even get in the position where someone could imply they might have looked at that source code.
Get the court to order discovery on all of your computers. They could probably also get subpoenas for the source code hosting sites to reveal relevant access logs. Or someone could admit to reading the source code someplace public, like a bug tracker. Or they could argue that the choice of variable names and minor details of algorithm details are too close to be coincidence. A jury convicted Google because of rangeCheck, after all.
> 2. If microsoft sued wine devs it would be horrible for Microsofts public image. They won't do it.
No it wouldn't, particularly not if they had a strong case (e.g., someone bragging about it). If you think MS looks bad for suing people for stealing the code, then you'd have to think the FSF looks bad for suing people for violating the GPL and stealing the code of, say, Linux.
> 3. I hope the WINE devs don't listen to you.
I hope they don't listen to you. The repercussions are quite large--it's not unimaginable that shutting down the WINE project could result from a lost case. These cases do happen, and defendants do lose (Oracle v. Google is a notable recent one, and that's based on IMHO fairly weak evidence). There's a reason that projects that do major reverse engineering for interoperability have rather elaborate procedures for doing so.
I agree with your, but there are people who argue this.
Complaining about the lack of source code is just sheer laziness.
https://www.microsoft.com/en-us/sharedsource/
I think this "leak" is greatly exhagerated.
https://www.betaarchive.com/forum/viewtopic.php?p=420025#p42...
C.
Useful for research, and finding security issues. Not much else.
But what data does this 8TB refer to specifically? Is this the source + all the windows builds from a plethora of sources? Did you download 8TB of data from BA and expand it to 32TB or was this a figure provided to you by one of the raided hackers or their associates?
>think the bigger issue is not the final size, but that internal Microsoft material - particularly source code - has escaped into public FTP
Happens regularly, although usually it's MS employees leaving stuff in public FTPs or inside released ISOs, updates, whatever. redmond\ domain is huge and the (accidental or not) leaks never stop.
What kind of an audit can you do without access to the original software's source code? How would you tell if it's actually different?
But IIUC, clean room reverse engineering requires substantial effort to prove you did not take any shortcuts.
You can break patents without ever knowing the patent existed. So looking at this code wouldn't trigger a new patent problem.
And simply looking at some code, closing it, then later writing code that does the same functionality is not breaking copyright. So looking at this code would not trigger copyright.
Not a lawyer, though, but a quick search confirms this.