Slashdot Mirror

Actually, for the comments, one has to go pretty deep, so here it is

Yeah, I too think that OS won't be around too long, so it will be down to FreeBSD and NetBSD. On the Linux side of things, even distros like Debian have discontinued support for things like HP PA-RISC, which is less ancient than VAX. FreeBSD has dropped support for DEC Alpha. That's what not just companies, but even volunteer organizations do when a platform is no longer in circulation. Yet that rack had a number of ancient boxes like VAX, PowerMacs, SPARCstation 20 (i.e. SPARC32), and more. Things that don't get built anymore.

He could cross-compile for older platforms on Xeons, while still keep currently selling boxes, such as HP Integrity servers, Sun SPARC and IBM POWERservers. He'd get his diverse architectures, and he'd save his electric bills. But since OpenBSD has a policy against cross-compiling, looks like they'll just have to go down.

Can nobody else fork OpenSSH, if he's threatening to end that if he isn't funded?

http://marc.info/?l=openbsd-misc&m=138972987203440&w=2

Meaning the project won't be able to cover 20 thousand dollars in electrical expenses before being able to use money for other things.

If you RTFML, you will see that Theo answered that:

http://marc.info/?l=openbsd-tech&m=138973837906139&w=2

Whether he answered it well or not is another question.

that particular bug you link was fixed a week before it was found to be security vulnerability (at the time was known to cause crash)

http://marc.info/?l=openbsd-misc&m=117404837006368&w=2

It prevents me from using OpenBSD on the R Pi.

It prevents me from developing my own OS for the R Pi.

It prevents me from having a system with complete source code, cuz you can't even boot without Broadcom's craptastic binary blob.

It prevents me from using the device any way I want to, and any way I can conceive of. I am limited to what Broadcom supports and approves of.

Is that enough???

Freedom isn't about practicality. Freedom is about LIBERTY. Freedom is about being able to do anything you can conceive -- anything you can think of. Freedom is about complete documentation, especially of all interfaces.

Your question is horribly misguided, and it proves you don't understand (or love) liberty and freedom.

Where does this myth come from

Since the late 90s there have been mumblings ("Someone I know who works at MS said they knew someone who said...") that code from BSD TCP/IP stack was in Windows but there was never any proof. Some speculated that because they were susceptible to some of the same vulnerabilities they must share common code but there were some vulnerabilities that affected the Windows TCP/IP stack not the BSD one (and vice versa) so this seems unlikely.

In 2001 the FreeBSD folks decided to search for proof but other than utilities nothing much was found. You can even see them correcting the "Windows uses the BSD TCP/IP stack" misconception years later.

Around the same time an article saying Microsoft uses open source code was published in the Wall Street Journal. Here's a quote:

Software connected with the FreeBSD open-source operating system is used in several places deep inside several versions of Microsoft's Windows software, such as in the "TCP/IP" section

This assertion is somewhat broard but it was enough to kick off a new round of speculation and rebuttals with regard to the Windows TCP/IP stack but everyone loves a good tale so the counterclaims are less well known. Perhaps this would qualify as a Snopes urban myth.

[H]ow did it end up being passed of as fact on wikipedia?

Who says Wikipedia only consists of facts? :-) Nothing saves you from having to use critical analysis on sources, especially since anyone can edit Wikipedia but I will note there is a citation needed link further down on that page.

All the above sources were found via a Google Windows/BSD stack query so with these starter links and a quick search you're now well armed to correct Wikipedia and anyone else who repeats this rumour. Welcome to the club!

Nobody is completely safe. Even OpenBSD. In light of these new Snowden docs, the following post by the OpenBSD author makes quite a lot of sense. Theo is accusing certain developers of being paid to backdoor the OpenBSD IPSEC stack dating back to 2000/2001 which coincides with the current revalations.

Theo de Raadt's post to the openbsd-tech mailing list.

"After Jason left, Angelos (who had been working on the ipsec stack alreadyfor 4 years or so, for he was the ARCHITECT and primary developer of the IPSEC stack) accepted a contract at NETSEC and (while travelling around the world) wrote the crypto layer that permits our ipsec stack to hand-off requests to the drivers that Jason worked on. That crypto layer contained the half-assed insecure idea of half-IV that the US govt was pushing at that time. Soon after his contract was over this was ripped out. ...

"I believe that NETSEC was probably contracted to write backdoors as alleged."

I'd like to find a more recent report of what they found.

"After Jason left, Angelos (who had been working on the ipsec stack alreadyfor 4 years or so, for he was the ARCHITECT and primary developer of the IPSEC stack) accepted a contract at NETSEC and (while travelling around the world) wrote the crypto layer that permits our ipsec stack to hand-off requests to the drivers that Jason worked on. That crypto layer contained the half-assed insecure idea of half-IV that the US govt was pushing at that time. Soon after his contract was over this was ripped out. ...

"I believe that NETSEC was probably contracted to write backdoors as alleged."

I'd like to find a more recent report of what they found.

"You want to dump backwards compatibility? Windows? Our core product we sell everything else on top of? THAT HAS TO BE THE WORST IDEA EVER"

They might get away with hiring Linus Torvalds for this actually. (eg. http://marc.info/?l=linux-acpi&m=136157944603147&w=2 )

Sarah Sharp is not asking the LKML to change its behavior for her own benefit but rather for the benefit of the developers that use it. It seems like a totally reasonable request from a long-time kernel maintainer (and Linus treats it as such) unless you make the assumption that's she's only asking because she's a woman. I think too much of the commentary here is based on that assumption and the "corollary" that her comment means she can't "take the heat".

Disclaimer: I know Sarah Sharp professionally. These are my views, not my employer's (I just started as MS a few months ago).

No, you are projecting your own perspective onto 'the rest of the world.' 'the rest of the world' doesn't use linux because windows is good enough for most uses and has established business software. That momentum is hard to beat. This has nothing to do with the behavior of the kernel devs on their own damn mailing list..who 99% of the user base never talk to anyway. This mailing list has been in operation with its own established culture for over 20 years, which proves that it works for them. Then she comes along and starts preaching and whining, and because she's a woman, this ultra PC culture expects them, as men, to get their manginas all hot and bothered over it. Linus said to hell with that and I agree.

Technical correctness > political correctness should rule the day, and I'm glad that's what linus intends. She can fork the kernel and create her own project; make her own 'diversity' distribution that's maintained by vetted politically correct maintainers who bend over backwards to never offend anyone, even if it causes more work for more people, and more trouble for more users, later on.. Then she'll find out for sure whether anyone with any technical knowledge will really want to put up with that long term.

http://marc.info/?l=linux-kernel&m=137398683002304&w=2
This guy's example is right on the money. Political correctness and the obsession with everyone's damn feelings routinely gets in the way of productivity, especially when management tries to graft it on to their employees.

http://marc.info/?l=linux-kernel&m=137394282220615&w=2

relevant part: "But whenever I need to send a patch to him, I tend to be more careful not to make mistakes."

If Linus wasn't so strict he would not be more careful to make mistakes. If he would, he wouldn't write this.

See the difference ?

For me, the softer the environment is, the bigger chance i'm gonna make a mistake.

For as much as I respect Linus for the work he's done, his outbursts are getting old and are not funny anymore

In my opinion, the above is some high way to miss the point (one doesn't expect Linus' outburst to be funny, does one now?)
Now, some quotes to see exactly what is the point, in Linus' own words:

So as far as I'm concerned, the discussion is about "how to work
together DESPITE people being different". Not about trying to make
everybody please each other. Because I can pretty much guarantee that
I'll continue cursing. To me, the discussion would be about how to
work together despite these kinds of cultural differences, not about
"how do we make everybody nice and sing songs sound the campfire"

Do you think you might be interested in *that* kind of discussion
instead of the "you are abusing me" kind of discussion?

In other words: "Kernel, MF! Do YOU speak it?"

I guess he does enjoy being a dick, but he doesn't associate his bad temper with being Linux's creator, this can be easily checked in his first answer, here: http://marc.info/?l=linux-kernel&m=137392506516022&w=2

Why backdoor just one brand of compiler (since there are several), when you could backdoor the architecture? I'm pretty sure there is a special sequence of intel instructions which open the unicorn gate, and pipe a copy of all memory writes to NSA's server.

Right, in fact, Theo de Raadt specifically warned about exploitable bugs in the Intel Core2 cpu. http://marc.info/?l=openbsd-misc&m=118296441702631

Mmm? Are you sure that's enough? It wouldn't be quite the first time NSA would have "helped" someone.

http://marc.info/?l=openbsd-tech&m=129236621626462&w=2

Some guy claimed to have put backdoors in the OpenBSD IPSEC stack for the FBI, but a full audit proved no such thing ever happened.

I seriously doubt this is happening in open source.

One great innovation is the combination of python and fortran.

Huge agreement here!

I advocated the same Ruby/Fortran synergy back in 2006, with a working example:

http://marc.info/?l=ruby-talk&m=115619337609191&w=2

Completely agree that this is a great way to use the best tool for the job. I'd go so far as to claim that Python(or Ruby)-with-Fortran is a better tool for most jobs than C#-for-everything, which is kinda mediocre at all tasks..

The mailing lists. misc@ tech@ for starters. Go to openbsd.org and sign up, or browse them on http://marc.info/

Work is being done on importing KDE 4 into the ports tree. Besides that, the Gnome and Xfce ports are quite up to date and work pretty well.

"That a Microsoft-signed Linux secure boot key could be used to hack systems. Microsoft could disable the key, which would then disable *Linux* systems. We can argue about whether Microsoft would actually do this, but understandably, Linus isn't excited about placing that kind of power in anyone else's hands."

You're actually reading Linus' argument exactly backwards.

Howells and Garrett argue that revocation is a significant possibility, _therefore_ we (distributions) need to do kernel module signing (because unsigned kernel modules are an attack vector against a Windows install on the same system). One strand of Torvalds' argument is that MS is never going to revoke any keys anyway, therefore we (distributions) don't need to bother. There are other strands to his argument, but that's how the revocation one goes. That's what http://marc.info/?l=linux-kernel&m=136185309010028&w=2 is about: key revocation is what he describes as an 'unlikely and bogus scenario'.

about charger when running nativ http://marc.info/?l=linux-omap&m=135188391620044&w=2

The more recent patch at http://marc.info/?l=linux-kernel&m=135105626207228&w=2 fixes stuff.

Opensource systems have their share of holes, and the idea that there is a gigantic pool of people qualified to catch backdoors in something as relatively simple as a web browser-- let alone an OS-- is absurd.

It doesn't take "a gigantic pool of people qualified to catch backdoors" to fix software bugs. If it did, closed source projects would be inherently hoplessly doomed security wise. What it does take is a few or even just one qualified person to catch backdoors. For closed source, the lure of money is usually enough to hire qualified people to do the job, presuming the owner of the code cares to offer such a lure. For open source, the idea is that statistically, there's such a gigantic pool of people out there interested at all with the code that presumably a few qualified people will be in the lot and find the backdoors.

Just because you can look at the source doesnt mean you can do a remotely competent job of auditing it; and the idea that a single person could somehow audit hundreds of thousands of lines of code for security "on a whim" is even more absurd.

Not so much "on a whim", but there's been multiple security audits by researchers from different universities, often in testing automated code checkers. The same presumably happens against Windows code too, as MS offers access to source code to universities for presumably the same reason. Having said that, it's an actual known when it's done with Linux because there's no NDAs to hide any of the source or otherwise hold back the results from public scrutiny. And probably just as important, it might take a competent person to find the bug, but it often doesn't take a competent person to fix the bug--in part because often researchers spell out the fix. Yet, MS is the only one can fix their bugs--short of some potentially nasty reverse engineering--while there's a gigantic pool of people who can fix the open source bugs.

There are a lot of benefits to open source, but sometimes its advocates really stretch the imaginations with some of the claims and accusations they level against proprietary software.

Well, it's not much of an accusation to point out that Oracle and Adobe frequently learn of security vulnerabilities and seemingly sit on them for months or even years, with no reasonable possibility of anyone else offering a fix--again, short of some nasty reverse engineering. Meanwhile, as much as open source bugs have been discovered, announced, and a few times ignored, the barrier is a lot less as a point to fixing such bugs with open source--with some exceptions on the complexity of reproducing the needed build environment, at times.

So I suppose the whole potential IPSEC backdoor in freeBSD thing was just my imagination, then?

You mean OpenBSD? And you notice that it's still only potential-at least, AFAIK--with no code audit so far showing any evidence of a actual backdoor? Meanwhile, in Windows world, if one of the developers on the MS IPSEC code was paid by the FBI, would MS tell us about the potential IPSEC backdoor, would MS do a code audit, would we be aware of that code audit, and would MS bother telling us everything looks okay? You see, as horrible as the whole situation might be with the potential OpenBSD's IPSEC backdoor, the fact that we know about it gives us the option to audit the code or to outright avoid the code because we know of the potential threat. Meanwhile, it's much harder to trust that a corporation, which has a vested interest in keeping as quite as possible about potential vulnerabilities as it risks their bottom line, will be open about the risk to their customers. Sometimes they try to rationalize it within the scope of "responsible disclosure". But it's only really responsible if one presumes that (a) users must use the relevant code and (b) not revealing

I don't really understand how anyone can care whether a closed source operating system is secure.

This is so much garbage.

Opensource systems have their share of holes, and the idea that there is a gigantic pool of people qualified to catch backdoors in something as relatively simple as a web browser-- let alone an OS-- is absurd. Just because you can look at the source doesnt mean you can do a remotely competent job of auditing it; and the idea that a single person could somehow audit hundreds of thousands of lines of code for security "on a whim" is even more absurd.

There are a lot of benefits to open source, but sometimes its advocates really stretch the imaginations with some of the claims and accusations they level against proprietary software.

it's sufficiently open that blatant backdoors are not going to be inserted.

So I suppose the whole potential IPSEC backdoor in freeBSD thing was just my imagination, then?

Youre talking nonsense. Consider that OpenSSL is widely considered a horrendously complex pile of spaghetti code, which I believe has had its share of security issues, and yet we still use it. Is it because we're lazy? No, its because sometimes some of this security stuff is phenomenally complicated, and it would take a horrendous number of man-hours from incredibly talented people to refactor or replace it.

One of the benefits of paid software is that, if theyre competent, they can devote a lot of time to it because they are paid. Im gonna go out on a limb here and say that one of the biggest helpers to good code in a lot of OSS projects are the paid volunteers, not the mere fact that its "open" as if that dash of pixie dust makes a project magically better.

Hell if you are worried about power you can buy one of those little plug computers or my personal favorite the little cheap E350 AMD kits. Those things are cheap, make great mini-servers or office boxes, only draw about 18w under load and less than 6w on average, great little units

Seconded, however you'd best steer clear of the Asus and Asrock boards if you plan on doing anything with the PCI slots on those boards. They all use the ASMedia 1083 pci bridge, which happens to be broken beyond belief. See here and here. TL;DR: the controller has a hardware bug where it fails to deassert its interrupt status, causing IRQ storms which effectively makes connected devices useless.

The only way out of this is to use an open source operating system where you can do your own code review, and where one guy doesn't have a bottle neck of control.

Yes and no. Open source doesn't guarantee security. For example, BIND had a long history of bugs (many of which involved security) due to poor design prior to version 9. You didn't need a mole or any malicious intent when the software was so full of big holes you could drive your car through them. OpenBSD had an alleged FBI back door in the news a couple years ago that had lain unnoticed for years.

Then again, there are examples of open source uncovering security issues. A quick google search uncovered this old one and this more recent one. By the way, if it sounds like I'm picking on BSD, I was searching for that FBI link. The other stuff just popped up. I know the various BSDs have a reputation for stability and security.

The patch itself : http://marc.info/?l=git-commits-head&m=114223318030280&w=2

I have been an early adopter of many things. But I value my data (which is my bread and butter, after all), and so I will take a conservative approach to this. After more people have had them, for a little while longer, I will revisit the issue then.

If you value your data then no single drive is good enough. The only answer is RAID (1 or 5 typically). If you don't feel like buying two SSDs and you use Linux, then put it in RAID 1 with a regular hard drive using software RAID and write-mostly+write-behind for the HDD. Also remember that you are just as likely to delete a file you care about as the hard drive is to fail. So don't forget about backups, and offsite backups if you can.

There are multiple code branches of Windows (LDR vs GDR)

I had never heard of LDR vs. GDR until now, apart from GDR being the former East Germany, so I went to Google and typed in windows ldr gdr. It gave me this post:

If updates are only delivered from Windows (or Microsoft) Update (including via WSUS), then all the files remain on the GDR branch.

So in laptop and home situations, where nobody uses anything but Windows Update, what's needed for servicing other than GDR?

and the old files can be needed for future servicing

If the method of servicing used by Windows requires keeping 18 GB of unused files around, then the method of servicing used by Windows is space inefficient, and therefore Windows is space efficient.

According to http://marc.info/?l=apache-httpd-dev&m=131418828705324&w=2 the correct syntax is:
RequestHeader unset Range

The internal crypt() function of PHP is only there whenever the system function doesn't exist.

This is not correct.

Ondrej's post you link to is specifically referring to the patched version of PHP that you get from the Debian repository. One of the patches Ondrej applies makes PHP use the system crypt(). Without that patch -- with the stock PHP code -- PHP uses its own crypt(). Now, other distributions might apply Ondrej's patch, but I certainly wouldn't count on it, and you definitely will have a broken crypt() if you get the stock PHP.

For my source, I again cite an email from Ondrej, this time to the PHP list http://marc.info/?l=php-internals&m=131404279532421&w=2

In that email, he suggests to the PHP folks that they should apply his patch.

*WHAT* century are you living in? In the 1990s, Adaptec was a good brand. Not any more. Not just not good, but actively sucky.

http://marc.info/?l=openbsd-misc&m=125783114503531&w=2
http://marc.info/?l=openbsd-misc&m=126775051500581&w=2
http://marc.info/?l=openbsd-misc&m=128779369427908&w=2

(Read 'em in order)

Adaptec: another way of saying "my data is not important"
Adaptec: unsafe on any platform.

*WHAT* century are you living in? In the 1990s, Adaptec was a good brand. Not any more. Not just not good, but actively sucky.

http://marc.info/?l=openbsd-misc&m=125783114503531&w=2
http://marc.info/?l=openbsd-misc&m=126775051500581&w=2
http://marc.info/?l=openbsd-misc&m=128779369427908&w=2

(Read 'em in order)

Adaptec: another way of saying "my data is not important"
Adaptec: unsafe on any platform.

*WHAT* century are you living in? In the 1990s, Adaptec was a good brand. Not any more. Not just not good, but actively sucky.

http://marc.info/?l=openbsd-misc&m=125783114503531&w=2
http://marc.info/?l=openbsd-misc&m=126775051500581&w=2
http://marc.info/?l=openbsd-misc&m=128779369427908&w=2

(Read 'em in order)

Adaptec: another way of saying "my data is not important"
Adaptec: unsafe on any platform.

Looks like the bug is fixed . so we might see Linux-3.0 in a couple of days. http://marc.info/?l=linux-kernel&m=131104131518622&w=2

In the meantime I'd love any pointers at all to where you can buy the systems they used for development and testing - apparently you can actually buy systems with infinite memory so you can do extensive testing and never notice firefox has a memory management problem.

Number of firefox crashes while typing this comment: four.

The thread on marc.

IPV6 has implementation issues, AND it has some engineering mistakes built in. it's not that simple.

http://cr.yp.to/djbdns/ipv6mess.html

http://marc.info/?l=openbsd-misc&m=128822984018595&w=2

A link to Theo's post on the subject is much more informative.

Highlights:

• Two of the guys named in the original allegation did work on the security stack, but
• Almost certainly didn't check in any malicious code, and
• "wrote much code in many areas that we all rely on. Daily. Outside the ipsec stack."

Also:

I believe that NETSEC was probably contracted to write backdoors as alleged. If those were written, I don't believe they made it into our tree. They might have been deployed as their own product.

Since the useless summary did not include one

http://marc.info/?l=openbsd-tech&m=129296046123471&w=2

There are already admissions made by Theo and others that there *are* some security problems with the code in question, which have been addressed with commits on 12/15 and 12/16 of this year. Whether or not these are the "backdoors" originally referred to is unknown. Here's validation of my statement -- read the entire post from De Raadt, as it includes admissions as well as the commits themselves. And don't forget to read the very last paragraph of his post too.

http://marc.info/?l=openbsd-tech&m=129296046123471&w=2

Does this mean OpenBSD is insecure? No, but it does mean that the "fuss" you refer to has actually brought to light things that were in fact missed in the past. Draw your own conclusions from that.

There is refutation from Jason; http://marc.info/?l=openbsd-tech&m=129244045916861&w=2

There are number of developments. Challenge to find backdoor: http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-ipsec-backdoor-allegations.html Jason Wright's response: http://marc.info/?l=openbsd-tech&m=129244045916861&w=2

http://marc.info/?l=openbsd-tech&m=129237675106730&w=2

You haven't read that mail if you are saying that. Just read the damn mail! http://marc.info/?l=openbsd-tech&m=129236621626462&w=2

Oh please, de Raadt didn't claim shit. Here's the original mail.

Theo seems skeptical himself, he just didn't want to hold back a potential security issue.

It seems that link may have been /.ed. They are doing precisely as you say.

Here is a dump of the information, last I had it.

IRC: irc.freenode.net #openbsd
Twitter: OpenBSDGate

The etherpad (most detailed and up to date):
OPENBSD IPSEC STACK VERIFICATION

Original Email:

http://marc.info/?l=openbsd-tech&m=129236621626462&w=2

The code:

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ipsec_input.c
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/netinet/ipsec_output.c

Misc:

What other software includes the OpenBSD IPSEC implementation?

Not Linux:
Triaging Linux; git clone git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
Initial commit 6c55c29fa, Oct 2002, Alexey Kuznetsov
Does not appear to be derived from the above? (checking strings from ipsec_input.c version 1.54.2.3, Oct 2002). Neither copyright information nor comment strings match. Linux's IPSec implementation looks original.
'git log -p --grep=IPSEC' on the above clone shows complete history for the period.

Communications:
IRC: irc.freenode.net #openbsd
Twitter: OpenBSDGate
PublicPad (this document); http://piratenpad.de/condition-beige

Press:

http://blogs.forbes.com/taylorbuley/2010/12/14/fbi-accusedipsec-of-decade-old-cryptography-code-conspiracy/
http://bsd.slashdot.org/story/10/12/15/004235/FBI-Alleged-To-Have-Backd

We have never allowed US citizens or foreign citizens working in the US
to hack on crypto code (Niels Provos used to make trips to Canada to
develop OpenSSH for this reason), so direct interference in the crypto
code is unlikely. It would also be fairly obvious - the crypto code
works as pretty basic block transform API, and there aren't many places
where one could smuggle key bytes out. We always used arcrandom() for
generating random numbers when we needed them, so deliberate biases of
key material, etc would be quite visible.
oored-OpenBSDs-IPSEC-Stack
http://www.reddit.com/r/programming/comments/elw0x/allegations_regarding_openbsd_ipsec_fbi_backdoors/
http://www.metafilter.com/98547/Subject-Allegations-regarding-OpenBSD-IPSEC

Docs:

http://web.archive.org/web/20000621015208/www.netsec.net/gsa.html
https://www.gsaadvantage.gov/ref_text/GS35F0040K/GS35F0040K_online.htm
http://web.archive.org/web/19980101000000-20040101235959*sh_re_sr_1nr_30/http://www.netsec.net/*
http://web.archive.org/web/20000816024729/www.netsec.net/ltr_doj.html

Source Contributors:
Jason: http://www.linkedin.com/in/jasonwright

Possibility #1: (eldragon)
http://www.openbsd.org/cgi-bin/cvs

Well... You forgot the third option: the possibility that the exploit is genuinely tricky and fiendish. Get a load of this post, where an OpenBSD dev takes a stab at where such a problem might lie. Item 4 in that link is particularly voodoo; it involves observing CPU time when you know the crypto stack is performing a specific operation (memcmp being the example given) and deducing the key from that.

Imagine an attack like this: "since you did this loop a certain way I can predict the key based on how slow the CPU cache is acting on a probe of some buffer." Not exactly something that's easy to spot in a code review.