Hacker News new | past | comments | ask | show | jobs | submit login

My immediate thought is whether researchers or investigative journalists will find cold hard US government backdoors. This is potentially big.



They won't. Such backdoors would have to be hidden from Joe Average Coder at Microsoft first and foremost. Coding for MS is not a livelong thing, you know? So any backdoor would a) be obfuscated and b) have some form of plausible deniability. If I would have to make them, they would look like strings of two or three bugs.


Likely you're right, but let's see if anything can become plausibly demonstrable after obsessive scrutiny. Like many situations in life, it may depend on whether someone determined / resourceful enough wants to do this. There may be no one with sufficient motivation.

Also, it's not just (allegedly) all of XP source that's been leaked:

https://www.bleepingcomputer.com/news/microsoft/the-windows-...

It's also Windows Server 2003, MS DOS 3.30, MS DOS 6.0, Windows 2000, Windows CE 3, Windows CE 4, Windows CE 5, Windows Embedded 7, Windows Embedded CE, Windows NT 3.5, and Windows NT 4!

That's a huge amount of stuff to analyse.


It would be nice to have a Github repo where you can browse the history like for Unix at https://github.com/dspinellis/unix-history-repo . Not going to happen, of course.


Do you know if there is source code for classic Windows apps like the Calculator, Notepad or Paint? Would love to recreate those simple apps and chuck the lousy Linux/Mac equivalents.


I am not sure if it is what you are looking for, but the calculator is now open source under the MIT license https://github.com/Microsoft/calculator

As a recall, making notepad is like a homework assignment for a visual basic class. You just drag the text editor window and add the menus, there isn't a whole lot there!

Paint would probably be a bit more work, but there are a few clones out there already


Really looking to build a tool with the same look and feel. Launches fast, can just paste text stripping formatting and then allow you to save it as txt or copy it as is to other apps. A typical Ubuntu install gives you something like gedit2 or pluma. Too much for a text editor. Same goes for Paint. I can't believe that I have to install a heavy app like Gimp, Pinta or Krita. They are significantly more heavy and less stable in my experience. The simplicity of these tools make their brilliance.

The same goes for Mac. Mac has "textEdit" and "Notes" apps but it handles formatting, is slower to launch and is more of a Wordpad clone. For Paint, their Preview tool is terrible. I just want to take a screenshot, paste it in a file, maybe add a red circle or square and save it as png. Quick and fast.


Notepad is simple to build in Visual Basic because it uses the controls that are inherited from... notepad.

What GP meant, is whether the source for those controls is available.


Notepad is simple to build in Visual Basic, Delphi, heck even assembly because the controls are inherited from Windows[1].

[1]: https://docs.microsoft.com/en-us/windows/win32/controls/indi...


There is no reason to build them for Windows. I just use the ones already available for Windows. I want to build it for Mac so I can get the great simple tools on Windows but on the stability of Mac. For Paint I have resorted to buying a Mac Store app called Paint2 made by some Chinese developer. It is still too complex but is the best I can do now.


There's always Ken Thompson's hack of the compiler to insert a backdoor into the login program on Unix. See Reflections on Trusting Trust: https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html .



If it really does exist, the backdoor can simply be inserted during the last-minute compile before release. It would be invisible in the code repository, the vast majority of internal developers at Microsoft won't even see anything unusual. Also, I heard anecdotes that Microsoft already allowed governments to audit the source code of Windows under NDA on multiple occasions in the past.

But if you cannot guarantee the correspondence between source and binary releases, such a review only helps a little. Reproducible build is crucial for auditability.


> I heard anecdotes that Microsoft already allowed governments to audit the source code of Windows under NDA on multiple occasions in the past.

I can confirm that back in the Windows 2000 days, MS let a major global bank have access to the Windows 2000 source code to aid them in coding some low level bespoke software.

Back then, if you were a gold customer, you could pretty much get anything out of MS under an NDA.


'MS let a major global bank have access to the Windows 2000 source code to aid them in coding some low level bespoke software.'

Examples of this are comparatively well known but it seems to me it's really not relevant here. In those instances it's extremely unlikely that said institutions would have access to even the majority of the source code let alone all of it.

All they need are API hooks and or various security code that's relevant for their purposes, etc. If I were the Microsoft person responsible for interfacing with these banks, I'd do what I've done with unrelated stuff, which is to tell them just sufficient to do the job (that's to say only on a need-to-know basis).


And that's why modern compilers won't have that. It was exactly so the same source, even compiled a second later, it will generate different binary file.

I hate it. It was so easy in DOS era - same source, same binary file, easy peasy.


The major variables in modern compilers are just automatic timestamps, exploit mitigation random seeds, and toolchain versions, it is possible to make them immutable. The problem can be fixed, and there are already major projects to address it. Do you know that 90% of the Debian packages are already reproducible [0]?

[0] https://isdebianreproducibleyet.com


That’s true. But that may also be a plausible deniability thing - you create a place to hide binary modifications by making sure no two builds are exactly the same.

It could be chalked to some lack of care; however, up until 2000 or so, non reproducible builds were considered a bug in at least two places I worked in. The fact that it has become so hard to make builds reproducible could be Increased “entropy” (because no one cares To fix it) - but it could also be orchestrated by someone with a vested interest.

E.g. - suppose you are a three letter agency, and want to implement a “reflections on trusting trust” attack. Non reproducible builds become a pre-requisite.


No disagreement. It's why the problem needs to be fixed, although it's not a silver bullet (the compiler bootstrapping is still vulnerable).


The reproducible builds folks are working on fixing that:

https://reproducible-builds.org/


Most modern compilers have switches to disable this behavior.


This is correct. Back at least in the Vista days each public release had to be passed to the NSA to validate the encryption algorithms and implementation. I’d imagine they poked around a few other parts of the OS


> each public release had to be passed to the NSA

That sounds a lot like a conspiracy theory. Any references on this?


The NSA has a dual mandate - to improve security for the US government (and by extension, US businesses to an extent), and to peek into communications outside the US.

They have been pretty negligent about the first (or even malicious about it - e.g. the dual drbg case), letting the second take over - but officially they still have the first mandate.

In fact, DES was considerably strengthened in its day by the NSA review - at that time for reasons not understood by industry or academia. It was later discovered that the change required by the NSA made DES much more resistant to differential cryptanalysis, a technique that was (re)discovered by academic cryptographers much later.

Every “conspiracy” I’ve heard about the NSA and friends turned out to be true, most with definite proof from the Snowden releases.


> Every “conspiracy” I’ve heard about the NSA and friends turned out to be true

And therefore every next thing anyone on the Internet concocted has to be true as well?

I get what you're saying though, and I'm well aware of the dual mandate. But you haven't given me anymore reason to believe this particular one, and I find it strange because I've never heard of any company in any country having to give their software to an intelligence agency before being allowed to release only the modified version. Implanting backdoors is not unheard of, but after they had great success with the clipper chip it's usually done without the company in question knowing about it.

You say the excuse was to validate some implementation, but in that case Microsoft wouldn't need to publish any modified versions, the nsa would just point out "this contains too strong crypto, can't export this" or "you made a mistake in algo X allowing attack Y". Not "please substitute this dll with our version and better not tell your customers!".


You are reading too much into cududa’s comment and mine, quite a bit of things neither of us said.

Cududa mentioned Microsoft let the NSA review it - that it was procedure, not that it was law. Furthermore, no one claimed that NSA recommendations or replacement DLLs had to be used by law - though that makes little difference. I mentioned that this would be in line with well known history of DES development. That’s basically all we said about it.

I have no idea what you are referring to with the Clipper chip. But RSA, NIST and others were definitely aware they were peddling NSA recommendations With the dual-drbg fiasco.


EternalBlue was probably the biggest backdoor used by the US government for years and even Microsoft (at least officially) didn't know about it. Finding and not reporting bugs is much easier than getting a company to put in backdoors without anyone blowing the whistle or objecting.


I'll reply with my own doubt myself:

There's a possibility the leaked files are tampered from the original code anyway, i.e. backdoors were removed before being initially leaked. Rationale being that Microsoft / government wanted to control the situation long-term by letting something tampered be what leaks out underground instead of the 100% full thing.

Torrent poster also discusses that possibility: https://www.reddit.com/r/windowsxp/comments/iz46du/the_windo...

Nonetheless, it's interesting if anything plausible is found.


There have always been rumors about such back doors, but even the public ones, encryption schemes, have never been proven by pure analysis. As far as back doors in code goes, have a look at this: http://underhanded-c.org/. It's a pity it seems to have been short lived.


“Never been proved” is correct, but this proof is quite a tall order.

Remember, almost everything in the Snowden disclosures was known before snowden - but generally dismissed as “conspiracy theories”.

None if it was proved, until it was.


Then it needs some authoritative source, a leak, or result of a raid. Which was my point: analyzing the Windows XP code most likely is not going to prove there's a US mandated backdoor.


Plausible deniability where people can look is a huge thing. Even where people can’t Easily look - e.g. Intel ME “firmware”, it’s likely done as shoddy/buggy coding, so Intel can just look incompetent (and not downright malicious) when it does come out.

Russia and China aren’t buying any of this, and are fabricating their own chips. 5-Eyes are likely in on the thing so no reason for them to set up their own fab facilities.

But setting up your own software ecosystem is much easier (especially given Linux / BSD), even though it’s still expensive - so intelligence agencies would rather not give countries incentive to do so just because there’s a back door.


That would surprise me. Governements all over the world already received access to the source code to perform audits.

Besides, probably the quality was still low enough that you didn't need this, there were plenty of bugs that would grant a big organisation access.


They got access to the source code, but not the ability to compile themselves.... my university had such access.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: