Linked by Thom Holwerda on Wed 21st Sep 2011 22:06 UTC, submitted by kragil
Windows After the walled garden coming to the desktop operating system world, we're currently witnessing another potential nail in the coffin of the relatively open world of desktop and laptop computing. Microsoft has revealed [.pptx] that as part of its Windows 8 logo program, OEMs must implement UEFI secure boot. This could potentially complicate the installation of other operating systems, like Windows 7, XP, and Linux.
Thread beginning with comment 490289
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Comment by OSbunny
by lemur2 on Thu 22nd Sep 2011 01:33 UTC in reply to "Comment by OSbunny"
lemur2
Member since:
2007-02-17

If you want to hide malicious code you can do it in open source as well. There was that news a few months ago about openbsd having malicious code. Don't know whether it was true or not but the possibility remains.


Quote please. AFAIK the track record is that malware has never been distributed to users via open source repositories. The only way it happens is to distribute modified code binary-only executables to Windows users.

Actually, you can't hide malware in the source code of open source software which is developed in collaboration by a number of independent programmers. The more people involved, the more impossible it becomes. If you want to inject malware, it has to be done AFTER taking the source code from the development project but BEFORE distributing binaries to end users, this is the only remotely possible point of injection. Even then, if the users can get the source and also the bianries and they can compile the source for themselves and check it, then even that possible point of injection is no longer possible.

Anyway I don't see MS succeeding in forcing motherboard manufacturers to disallow Linux installation.


The UEFI specification is not actually from Microsoft. Microsoft are simply saying that UEFI secure boot is required if an OEM wishes to put a "Designed for Windows 8" sticker on their hardware.

Arguably, if something is indeed "Designed for Windows 8", it is reasonable to expect that it can't run anything but Windows 8.

For myself, I put together my own desktop machines. I typically buy an "upgrade" package which includes a motherboard, CPU, RAM and box. I add a blank hard disk drive, optical drive and graphics card, plug it all together, insert a Linux LiveCD into the optical drive, and away I go. Doing this has been quite a bit less expensive for me than buying store-bought machines of equivalent performance anyway. The problem here is that the days of such machines are arguably numbered.

It shouldn't be a problem because the market is about to be flooded with a plethora of reasonable ARM tablets designed to run Android. E.g:

http://www.osnews.com/comments/25176

If you want to have a Linux desktop machine one of those can easily be adapted, just add a USB keyboard and mouse, HDMI monitor and USB external storage (or use a NAS device).

Edited 2011-09-22 01:40 UTC

Reply Parent Score: 0

RE[2]: Comment by OSbunny
by Lennie on Thu 22nd Sep 2011 09:10 in reply to "RE: Comment by OSbunny"
Lennie Member since:
2007-09-22

Actually it is possible to include something in an open source project, but you'll have to also modify the compiler and probably wait a few years to:

Thompson's paper described a modified version of the Unix C compiler that would:

Put an invisible backdoor in the Unix login command when it noticed that the login program was being compiled, and as a twist
Also add this feature undetectably to future compiler versions upon their compilation as well.

http://en.wikipedia.org/wiki/Backdoor_%28computing%29

It is not very likely, but it possible

Reply Parent Score: 4

RE[3]: Comment by OSbunny
by lemur2 on Thu 22nd Sep 2011 09:53 in reply to "RE[2]: Comment by OSbunny"
lemur2 Member since:
2007-02-17

Actually it is possible to include something in an open source project, but you'll have to also modify the compiler and probably wait a few years to:

Thompson's paper described a modified version of the Unix C compiler that would:

Put an invisible backdoor in the Unix login command when it noticed that the login program was being compiled, and as a twist
Also add this feature undetectably to future compiler versions upon their compilation as well.

http://en.wikipedia.org/wiki/Backdoor_%28computing%29

It is not very likely, but it possible


That was only possible because the Unix C compiler itself was not open source.

I repeat, it is not possible to put malware into a product using an open source development process.

BTW, Linux is not Unix. BSD is Unix, but Linux isn't.

Edited 2011-09-22 09:54 UTC

Reply Parent Score: 2

RE[3]: Comment by OSbunny
by bert64 on Thu 22nd Sep 2011 10:33 in reply to "RE[2]: Comment by OSbunny"
bert64 Member since:
2007-04-23

Such a backdoor would require fairly complex and specialised code, in an open source compiler that would be noticed so you could need to be using a closed source compiler...

The only realistic way to "backdoor" open source code, is to introduce a very subtle exploitable bug...
A blatant backdoor will be found quickly, whereas a bug may slip by...
Similarly, if your backdoor is found then you have deniability if it looks like a software bug, but if its obviously a backdoor you will likely be named and shamed, as well as blocked from any future commits.

You would also need to be a competent developer, and to commit a significant amount of legitimate code to a project in order to build up a level of trust first. It wouldn't be a simple quick attack, it would need to be planned and thought out well in advance.

And also note that all of the above also applies to closed source too, someone sufficiently motivated and funded could get someone hired by a software company to work on the target product. It's also been my experience that code written by an employee comes under far less scrutiny than code from a new contributor to an open source project.

Reply Parent Score: 6

RE[2]: Comment by OSbunny
by phoudoin on Thu 22nd Sep 2011 13:43 in reply to "RE: Comment by OSbunny"
phoudoin Member since:
2006-06-09

Arguably, if something is indeed "Designed for Windows 8", it is reasonable to expect that it can't run anything but Windows 8.


Nope.
You'll be right if the logo says "Designed exclusively for Windows 8".

But it's not. And, though, one can expect it could run *something else*, too.
The exclusive semantic is what's matter here.
And consumer should be able to know it's not a versatile computer but a Windows 8 only computer he's buying. And it should know it *before* doing it.

Otherwise, there's valid legal ground to sue the seller whose hide you it was not a Personal *Computer* but a *Windows 8 device*.

Considering prior tracks of personal computers sales, consumer is legitimate to think that any device sold under this product family "name" is a versatile computer, not a lock-down computing device.

Edited 2011-09-22 13:48 UTC

Reply Parent Score: 6

RE[2]: Comment by OSbunny
by malxau on Thu 22nd Sep 2011 20:08 in reply to "RE: Comment by OSbunny"
malxau Member since:
2005-12-04

"If you want to hide malicious code you can do it in open source as well. There was that news a few months ago about openbsd having malicious code. Don't know whether it was true or not but the possibility remains.


Quote please. AFAIK the track record is that malware has never been distributed to users via open source repositories. The only way it happens is to distribute modified code binary-only executables to Windows users.
"

Do you remember this? I believe the code was distributed over CVS, but never made it into a release.

http://www.theregister.co.uk/2003/11/07/linux_kernel_backdoor_block...

Or when debian ran valgrind on openssl and shipped a broken version for years before it was detected, resulting in piles of compromised keys? The code was there for all to see.

http://blogs.fsfe.org/tonnerre/archives/24

As a paranoid afterthought, note we only know about these when they're detected. We don't know about the ones that are too good - which may be zero or may be large. We have no way to know.

I think as everyone else is saying, it's difficult, but not impossible. The code just needs to look correct even when it's not. That's a high bar, but it can be met. There's even a competition over who can do it well:

http://underhanded.xcott.com/

Reply Parent Score: 3

RE[3]: Comment by OSbunny
by lemur2 on Thu 22nd Sep 2011 23:23 in reply to "RE[2]: Comment by OSbunny"
lemur2 Member since:
2007-02-17

"If you want to hide malicious code you can do it in open source as well. There was that news a few months ago about openbsd having malicious code. Don't know whether it was true or not but the possibility remains. Quote please. AFAIK the track record is that malware has never been distributed to users via open source repositories. The only way it happens is to distribute modified code binary-only executables to Windows users.
Do you remember this? I believe the code was distributed over CVS, but never made it into a release. http://www.theregister.co.uk/2003/11/07/linux_kernel_backdoor_block... "

I had not heard of that one, that is as subtle as it can get. Note that despite this attempt, my original statement is still correct, "the track record is that malware has never been distributed to users via open source repositories".

Or when debian ran valgrind on openssl and shipped a broken version for years before it was detected, resulting in piles of compromised keys? The code was there for all to see. http://blogs.fsfe.org/tonnerre/archives/24


This was a bug, an error, a mistake. It was not malware. Malware is where someone deliberately tries to put malicious code into the system for their benefit at users expense.

I repeat, AFAIK, "the track record is that malware has never been distributed to users via open source repositories".

As a paranoid afterthought, note we only know about these when they're detected. We don't know about the ones that are too good - which may be zero or may be large. We have no way to know. I think as everyone else is saying, it's difficult, but not impossible. The code just needs to look correct even when it's not. That's a high bar, but it can be met. There's even a competition over who can do it well: http://underhanded.xcott.com/


You have come up with just one unsuccessful attempt in over ten years of open source development, through countless versions, of many thousands of open source products.

One unsuccessful attempt. It was defeated by the very checks built in to open source development process, even as long ago as 2003. Now that open source development tools, such as git, have moved on from there, another such an attempt today would have considerably less chance of getting even as far as the one you identified from 2003.

Contrast this to the situation with closed source distribution on Windows, with literally hundreds of millions of Windows computers infected worldwide, and two million new pieces of Windows malware written every year.

It cannot be said definitively that an attempt to put malware into an open source product and get it shipped to users via open source repositories is absolutely impossible, but we can say that as far as anyone can determine (to a very high level of confidence), no such attempts have ever been successful.

One cannot prove a negative, but "the track record is that it has never been done" gets as close as you can, for all practical intents and purposes.

Reply Parent Score: 2