Full Disclosure mailing list archives
Re: Remote hole in OpenBSD 4.1
From: wac <waldoalvarez00 () gmail com>
Date: Mon, 6 Aug 2007 15:42:07 -0400
Hello: Maybe if their microcode where open or at least not encrypted (was DES?) we could disassemble it and see for ourselves. Right now it doesn't matters if you can read the source code of your entire operating system + drivers + apps or even your ROM. At the end "they got you" whatever you run there linux, windows, BSD whatever just pick (ohh yes you only need to send special "data" over the net and you could be running code even in ring -1 if you have control of the microcode). I wish I could have an electron microscope. Yes call me paranoid but this days you have to. Probably all of their CPUs from Intel, AMD and many others have several flaws buried inside them for years. Maybe exploitable by someone who by chance found one. That is not a surprise given the facts that we all have seen several flaws in the past to the point that they decided that the microcode should be updated. Great feature btw they realized too late about that. Any company considering to make a Neutral CPU? Think about that, emulation at full speed of several architectures PPC, SPARC, x86, x64.... (maybe even at the same time) reduced costs since the extra cost on microcode development and no copy-you-are-mine infringement since that would be code from somebody else. Many of us would be happy to pay for our freedom and by the way trow away dynamic translators. That will sell like water. Think about that. The next revolution ;) Yep maybe talking I'm loosing this vision. Ok one out of the basket. And yes Intel has made a lot of sh.. in the past in order to harm other competitors. They ended hurting users in the end. Remember the time you could buy Intel AMD or Cyrix without changing your motherboard? Ahh now the motherfuckers made you buy one or the other with their copycrap in the sockets. I probably would have AMD by now (In my opinion they have proven to offer better stuff in the long run maybe not high clocks but certainly higher performance or lower costs or better per watt performance or great features). Now there is VT and Pacifica, several versions of 3D now and SSE. And thanks to M$ (yes thanks a lot) we got compatible 64 bits. Otherwise they would be doing the same sh. Jaj maybe they end up copyrighting your opcodes. At the end lots of millions are lost for their fucking battle making things inoperative with each other. Programmers breaking their heads because we have to work and learn double triple ... ad infinitum. Users complaint because X soft is only compatible with 3D now/SSE or whatever thing and then almost nobody uses that (MMX at most). There should be laws that would prevent them from doing that kind of things that hurt everyone (including them) in the long run and make the life of millions of persons problematic just because they want to hold a share. That is not development. Period. And about the deRaadt thing being paid by AMD. Yes well maybe you are right maybe not. But then remember the "BP I watch too much Matrix Trilogy" crap just before Intel releasing their "shinning" hard. That is a bad taste joke. AMD is in fact safer than VT if combined with the proper hardware. Maybe in practice is not implemented by vendors (there is where the real problem would be) but then that is probably a first step to later move the Trusted Platform completely inside the CPU. Now who started the war "I pay a tech bitch" (sorry but that's what they are if they actually are paid for telling us lies) on the flaws side? ding ding INTEL... Again?!?! I'm not an x86 CPU historian but this is what I have seen so far (not in chronological order) and it stinks AMD makes 3Dnow ----> Intel makes incompatible SSE AMD starts to grab too much users on the low end market ---> Intel makes the socket copyrighted (of course AMD answers with the same) AMD 3DNow 2 ---> Intel SSE2 SSE3 SSE4 AMD makes 64 bits ---> Intel tries to make incompatible 64 bits and M$ says that there won't be a windows for that and Intel gives up. I would have preferred to give a final kick to CISC so actually didn't liked the AMD version but hey at least we have compatible things. AMD makes designs for up to 8 cores ---> Intel simply had to RUN (fortunately they could not do anything else) AMD makes Pacifica (Secure Virtual Machine) ---> Intel makes a low end version they called VT that only has a turn me off bit (fortunately something can be done about this) or... where is the SKINIT equivalent? Intel pays a tech bitch to distract buyers from buying "insecure" AMD chips ---> AMD pays a tech bitch to distract buyers from buying faulty/insecure Intel chips. At least that's what looks like in both sides. Of course who can proof that? Any of those "they are paying" claims could be true or not, there is no real evidence. Fortunately we can verify both fault claims. For the first one reading the docs, and for the other claims trying some POC with a CPU that is not updated. However M$ released almost silent updates for the microcode driver, that's some evidence that suggest that there is something wrong. Now if M$ is in the AMD side giving support to those claims well.. POC. Please let's have them. We already have the patch at least that fixes some of them right? Is this clear enough? We want to have some more compatibility and less "I want you to be mine" crap. At the end we are all paying all of that extra complexity in the silicon itself or in the software side without need. Can we have that? And about the OpenBSD project well, all of the projects (open or not) are vulnerable to that so I wouldn't point my gun to some in specific simply because I got in problems with one of the developers or dislike their comments. Certainly many open source projects are not the work of one person (although usually only few of them get the glory while many others do a lot of hard work too). And please avoid pretending to be someone else (you simply are not good enough to fake it properly) or picking catchy names in subjects which are far away from being what they are. I wonder what would you do if Gadi ends up signing emails. Jejej you would be pretending that it is signed but then some of us would be verifying and would report the fake message. Regards to everyone else Waldo Alvarez On 8/5/07, Gadi Evron < gadievron () yahoo com> wrote:
I formerly had a great deal of respect, bordering on admiration, for Theo deRaadt's refusals to compromise his open source principles, even in the face of stiff opposition. Although he has occasionally gone over-the-top, recommended some frankly very dubious changes to OpenBSD, and is regularly arrogant (which is even more annoying because he's so often right!), he's always remained consistent in his devotion to the cause of GNU/Free Software. Notice "formerly": my confidence in deRaadt has been soundly shaken by his latest round of unfounded aspersions cast against Intel's Core 2 line of CPUs. Instead of getting the facts with careful analysis and study, deRaadt has jumped the gun by trying to preempt proper research with posts to the openbsd-misc mailing list. This in itself wouldn't be so bad, but his only proper citation is a 404 page, and his only other source is an old summary of unverified errata from a hobbyist website. The lack of fact-checking and complete absence of any credible sources for his allegations is suspicious in itself, but he compounds it into a complete boner by making an equally unsupported claim that the supposed (in fact non-existent) CPU problems are security flaws: As I said before, hiding in this list are 20-30 bugs that cannot be worked around by operating systems, and will be potentially exploitable. I would bet a lot of money that at least 2-3 of them are. Without real references to backup his exaggerated concerns, deRaadt's post crosses the line into outright libel and scare-mongering. It's obvious when you know what to look for: the subtle use of neurolinguistic priming in emotive leading phrases such as "some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell out of us", "Open source operating systems are largely left in the cold", "hiding in this list", and so forth. This does not lead me to share Theo's purported fears; instead it leads me to believe that he's trying to unduly influence Intel's reputation with lies. I have an idea of why. It's the same reason deRaadt feels comfortable in saying that he'd "bet a lot of money" on Intel's Core 2 processors having multiple (not one, but several) security flaws originating from these errata. Namely, one of Intel's largest competitors has supplied the OpenBSD project with a substantial amount of monetary support since 2004, presumably because they can't compete even in the open source market without propping it up with a flow of money. They cannot maintain their position on the processor front, so they're resorting to buying out open source software developers. It's regrettably cheap to do so, even if they have deRaadt's prestige, because their business models stifle income and so a monolith such as AMD can trivially tempt them with greater incentives. In fact deRaadt is an easier target for "donations" because he makes it clear that he has no business model for OpenBSD. Intel, by contrast, have no discernable incentive to deceive or play down security flaws in their products; the consecutive f00f and FDIV bugs of the past have taught Intel that their best course of action is to face up to their errors and offer speedy fixes. DeRaadt's claim that Intel must "be come [sic] more transparent" is most unfounded, especially when one considers who stands to benefit from this anti-Intel arrangement; the connections between the AMD-ATI leviathan and deRaadt-driven projects are not hard to find. AMD make a point of emphasising OpenBSD's place in the "AMD64 ecosystem", and, as already mentioned, lends its deep pockets to deRaadt's grasp. And the connections go both ways too: deRaadt has a blatant chip on his shoulder regarding Intel. Ultimately, it hasn't been enough for deRaadt to level unsubstantiated libels at Intel, or to elicit spurious security fears about its solidly tested products. He's added an extra layer of hypocrisy on top by attacking Intel for being opaque and complaining about made-up fatal flaws in their Core 2 system. I would go as far as to posit that it is in fact deRaadt's system for running the OpenBSD project which has a fatal flaw. This escapade proves that deRaadt -- and by extension the OpenBSD project -- is simply too vulnerable to external influence from corporations with a vested interest and lots of lucre. ____________________________________________________________________________________Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. http://tv.yahoo.com/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Remote hole in OpenBSD 4.1 Gadi Evron (Aug 05)
- Re: Remote hole in OpenBSD 4.1 monikerd (Aug 05)
- Re: Remote hole in OpenBSD 4.1 Gadi Evron (Aug 06)
- Re: Remote hole in OpenBSD 4.1 wac (Aug 06)
- <Possible follow-ups>
- Re: Remote hole in OpenBSD 4.1 Michael Smythe (Aug 05)
- Re: Remote hole in OpenBSD 4.1 George Capehart (Aug 05)
- Re: Remote hole in OpenBSD 4.1 Joey Mengele (Aug 07)
- Re: Remote hole in OpenBSD 4.1 monikerd (Aug 05)