Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why We Can No Longer Trust Microsoft

pcmag.com

Post reply on HN
Print view View original

241–250 of 310 posts

Re: Why We Can No Longer Trust Microsoft

#241

Post by fixxer »

brudgers wrote: post #214
cs702 wrote: post #169

GNU/Linux, and Free software and hardware in general, look to be the BIG winners out of the NSA brouhaha, because all non-US governments, businesses, organizations, and individuals around the planet who need to safeguard their private or confidential information now have reason to mistrust proprietary (unauditable) software and hardware. Free, open software and hardware are less likely to have secret 'back doors' ins…

It would be grossly unprofessional of the three-letter agencies if they should have failed to run counter-intelligence operations upon the open source communities. Futhermore, given their resources to hire hackers and long history of infiltrating loosely affiliated organizations, it is hard to image that they have struggled to place moles deep within many critical projects. Open source communities have no membership…

I don't think it is wise to trust any system, open or not, so I agree with your thesis.

However, the fact that Linux source is available for review does make it more secure on a relative basis. Sure, it is naive to think a zero day couldn't be buried in there, but at least there is the opportunity for review. With a closed-source OS, we don't even have the luxury of a false sense of security.

Not to get all tin foily, but I'd be more concerned about hardware exploits if you're thinking in terms of "man on the moon" resources... where are all those chips made again?

Re: Why We Can No Longer Trust Microsoft

#242

Post by flyinRyan »

acqq wrote: post #239
flyinRyan wrote: post #235

Earlier quoted context omitted.

How does this deal with [1]? Also, how do you know that your disassembler isn't compromised? [1] http://programmers.stackexchange.com/questions/184874/is-ken...

Disassemblers produce assembly code, not the HLL code, so they are many orders of magnitude easier to write from the scratch than modern compilers. They typically expect human involvement as soon as there's non-trivial assembly-level engineered self-modifying code. Hopefully there's no much of such code in the results of the compilers we use. Also if you check the whole discussion you'll see I already discussed Ken's…

Ok, I appreciate this information (and I'm trying to follow the discussion but I didn't see you talking of Ken's work).

But I'm still curious; even though you can write the disassembler by hand, how can you be sure that you're compiling it with a non-compromised compiler? Or do you mean write it in e.g. ELF format directly (and that's assuming the OS isn't involved in filtering offending code, though it seems extraordinarily unlikely that the OS could be generally modified in such away without detection)?

Re: Why We Can No Longer Trust Microsoft

#243

Post by fixxer »

brudgers wrote: post #230
bentcorner wrote: post #219

Earlier quoted context omitted.

Is there any evidence of this? Certainly there is a single hacker out there that has been approached by the gov't or contracted for them for these purposes at some point, that is also willing to talk, even anonymously.

It's not the Lone Ranger. It's a business. Think of Federal employees at Fort Meade, who were hired to do the sort of work I am describing. Think of defense contractors with nondescript offices in Fairfax who hire those same employees after they leave the government and whose employees spend their days writing and pulling and pushing and merging open-source software. Think of $200,000 a year. Think of Edward Snowden.…

> It's asymmetric warfare. But the side without the money is disorganized and open and trusting.

The Snowden leak happened (as did Manning), so the Government is not as organized as optics would suggest. They are drowning in the data deluge just like everybody else.

Re: Why We Can No Longer Trust Microsoft

#244

Post by dllthomas »

acqq wrote: post #236
dllthomas wrote: post #218

Earlier quoted context omitted.

You're missing something. The idea is to take one compiler source (S), and compile it with a diverse collection of compilers (Ck being a compiler in C0-CK), producing a diverse collection of binaries that are compilations of S: (Bk = Ck(S)). Because the different compilers are almost certainly not functionally identical, the various Bk should not be expected to be bitwise identical. However, because they are compilat…

Please explain which exact steps and which assumptions would be needed to have a trusted GCC 4.8.1, both gcc and g++ and then keeping it trusted as the new releases appear. Then the same for LLVM.

I don't know enough about the details of the build dependencies for any of these projects to give exact steps. To get a known-clean build (that is, a build guaranteed to match the source) of GCC 4.8.1, plug the GCC 4.8.1 into the procedure I gave above:

In case it wasn't clear, k is used for indexing, and I use "function application" f(x) to mean compilation of x by compiler f.

"Take one compiler source (GCC 4.8.1), and compile it with a diverse collection of compilers (Ck being a compiler in { C0 = GCC 4.8.1, C2 = LLVM, C3 = icc, C4 = visual c/c++, ...}[1]), producing a diverse collection of binaries that are compilations of GCC 4.8.1: (Bk = Ck(GCC 4.8.1)). Because the different compilers are almost certainly not functionally identical, the various Bk should not be expected to be bitwise identical. However, because they are compilations of the same source, they should be functionally identical, or one of the original compilers was broken (accidentally or deliberately). So now we can compile that original source with the Bk compilers, and because these compilers are functionally identical, the results (Bk(GCC 4.8.1)) should be bitwise identical. If there are any differences, you can manually inspect them to determine what the issue is and either issue a bug report to the appropriate compiler, change the source (GCC 4.8.1) to avoid undefined behavior, or notify people of the attack present in the compiler in question, depending on what you find. This does involve some binary digging, but quite targeted compared to a full audit and it may well not be necessary at all."

Likewise for any of the others, but note that once you've got a known-clean build of any (sufficiently capable) compiler you could use it to build known-clean builds of the others.

[1] the more compilers and the more diverse the background of the compilers, the better; it may well be worth using quite slow compilers that are proven correct and/or implemented in other (possibly interpreted) languages for a high degree of confidence.

Re: Why We Can No Longer Trust Microsoft

#246

Post by flyinRyan »

kayoone wrote: post #36
LinaLauneBaer wrote: post #9

A couple of years ago at a Linux conference in Germany I had a discussion with a Microsoft employee at their booth. At that time I was a 'hardcore' linux user with no trust in Microsoft at all. The discussion with the employee went like this: Me: "Hello. Could you tell me what Microsoft is doing at this Linux conference? I honestly want to know that." Him: "We are here to show how our products can work well together…

A couple of years ago some microsoft sales employee probably didnt know about any of this. Also he is talking about mostly self-hosted MS services and i doubt the NSA really has access to that. Also found your conversation style to be quite cocky.

Keep in mind this was in Germany and it doesn't read like native English. I.e. you're almost certainly reading a translation.

Re: Why We Can No Longer Trust Microsoft

#247

Post by mtgx »

cs702 wrote: post #169

GNU/Linux, and Free software and hardware in general, look to be the BIG winners out of the NSA brouhaha, because all non-US governments, businesses, organizations, and individuals around the planet who need to safeguard their private or confidential information now have reason to mistrust proprietary (unauditable) software and hardware. Free, open software and hardware are less likely to have secret 'back doors' ins…

In times like these I wish Ubuntu wasn't made by a US company. It could've been a huge winner out of this, and they could've played used it to the full extent in their marketing campaigns. I'm not sure they can still do that. At least if the EU countries want to go about "standardizing" around one Linux distro (like China did), they will just pick one, and not have one for each country.

Re: Why We Can No Longer Trust Microsoft

#249

Post by flyinRyan »

versk wrote: post #41
LinaLauneBaer wrote: post #9

A couple of years ago at a Linux conference in Germany I had a discussion with a Microsoft employee at their booth. At that time I was a 'hardcore' linux user with no trust in Microsoft at all. The discussion with the employee went like this: Me: "Hello. Could you tell me what Microsoft is doing at this Linux conference? I honestly want to know that." Him: "We are here to show how our products can work well together…

I keep hearing this on HN and reddit, but I think this is a mainly an echo-chamber effect. I'd say its far more likely that the vast majority of people don't actually care or realise what was happening, or they do realise and still don't care. I'd be surprised if the NSA leaks have any noticable impact on Microsoft's revenue.

Actually people in Europe do care and I would expect something to happen as a result. I don't expect MS to go out of business, but it wouldn't surprise me if they lost certain key projects over the next decade.

Re: Why We Can No Longer Trust Microsoft

#250

Post by dllthomas »

flyinRyan wrote: post #242
acqq wrote: post #239

Earlier quoted context omitted.

Disassemblers produce assembly code, not the HLL code, so they are many orders of magnitude easier to write from the scratch than modern compilers. They typically expect human involvement as soon as there's non-trivial assembly-level engineered self-modifying code. Hopefully there's no much of such code in the results of the compilers we use. Also if you check the whole discussion you'll see I already discussed Ken's…

Ok, I appreciate this information (and I'm trying to follow the discussion but I didn't see you talking of Ken's work). But I'm still curious; even though you can write the disassembler by hand, how can you be sure that you're compiling it with a non-compromised compiler? Or do you mean write it in e.g. ELF format directly (and that's assuming the OS isn't involved in filtering offending code, though it seems extraor…

The more general and diverse the tools you use, the less likely they are all compromised in the same way, and the more likely any compromise will show up in other contexts. Using tools at different meta-levels may also be worthwhile (machine-code vs. interpreter).
Post reply on HN