Slashdot Mirror

Encryption weenies place a lot more faith in it's power than I do. So, are we supposed to trust SSL? I don't. Besides being eat-up with a laundry list of past vulnerabilities, I'm supposed to trust some megacorp that says some other megacorp or boiler-room-scam operation capable of issuing a certificate signing request is trustworthy? Why again? Just because they can pay folks to answer the phone or to supposedly check someone's business license? That doesn't mean *squat*. There are so many instances where that system has broken down due to technical and logistical reasons, it's not even funny.

You ever notice how everyone gets all concerned about algorithms being broken but it's usually the implementation that the hackers go after and break? What difference does it make if you have a steel vault door if it's mounted on a balsa wood frame? So, because of that fact, how is anyone supposed to trust anything that's "encrypted" ? You can't trust the OS to not be keylogging you, the feds or the author not to have backdoored the implementation, nor can you trust that someone won't simply beat the password out of user (ie.. rubber hose decryption method). If you ask me, the promise of encryption is a lie. It's marginally useful to obfuscate sensitive details in transit or for hashing. The idea that it can always be trusted and is some kind of panacea against hacking is laughable and been proven idiotic over and over, especially when pronounced upon high by evil megacorporations who have ZERO credibility anymore.

I got laid off from eBay in 2009. A few years later I came back to eBay to do a PC refresh project. When I needed to fix a problem for a user and got prompted for an admin password, I typed in the old password and it worked. When I brought it to management's attention, they changed the admin password — and gave me the new admin password. When I had a job interview at eBay a few years ago, they were taking security more seriously as they were hiring remediation techs to fix the Heartbleed Bug.

I am sorry, but if it was fixed in few days, it was not found in few days. This bug existed for many versions of OpenSSL before being finally discovered. That's not quite true to say it was discovered in days.

Microsoft had a flaw in Windows that lasted for almost 20 years before being fixed, and they also had one that took 17 years to fix, and another one that took 15 years to fix. There are many, many more with shorter lifespans but are just as severe in terms of how much they compromise. Heartbleed was in use for 2, being introduced in March 2012 and fixed April 2014.

My point here is that open source software has a better track record for security, and you don't seem to be really disputing that.

Just because YOU don't understand it, it doesn't mean that there are a LOT of people that do and would. I'm not knowledgeable enough to personally audit open-source encryption software like GPG and OpenSSL, but I'm glad it's open-source so others who are more knowledgeable than me can scrutinize.

Hahaha.. Cough! Heartbleed Cough! Undiscovered for 3 years (!) by all those scrutinizing eyes. (and no, it wasn't finally discovered because it was OSS, but buy automated testing that works equally well on closed source).

What an absurd statement this is making. I like the one about "Trust is of utmost value". No, not at all and let me explain why.

If I use open source software I use binaries. I have no more faith in those binaries than any other piece of closed source software, there's no guarantee that the binary matches the source, even if the source is somehow magically free of bugs because as we all know open source is infallible.

Ok so there's the potential for me to do an audit. So I have the choice, I could sit down and decompile the binary and audit it against the original source code, or I could download the source code and compile from source. Which now raises the question:

"Who in their right mind would go to this much effort securing software used to send plain text data over unsecured servers scattered around the internet?"

Did _you_ know that your wireless router was using OpenSSL to manage EAP? Or did you just assume that having SSH blocked and not serving HTTPS would be enough?

And even if you did, is it even possible for you to upgrade a single library on your access point?

Try going back to the original CVE, the plethora of vulnerability checkers, or any of the press surrounding it. Every reference to Heartbleed pointed to HTTPS or, rarely, TLS and VPN services as being vulnerable to the bug. Now pretend that you don't know the implementation details of WPA and EAP. Based on all of that, why would you even consider updating or replacing every wireless device you have which don't use HTTPS unless the manufacturer told you?

Moreover, when have manufacturers of popular wireless equipment _ever_ produced timely and relevant updates without at least eight months lead time and court cases in at least three countries?

The raw sockets deal - Windows added raw sockets, or more simply said the ability to manipulate Internet packets at a very low level. Mr Gibson acted as if the entire Internet was about to collapse. In theory it was a bit easier to make fake packets and try to mess with other computers, in practice malware that is embedded in the kernel could already do this, and the bad machines could only mess with poorly configured machines anyway. If you know networking, fake packets don't help TCP that much anyway, mostly fun to mess with UDP. There is a lot of damage you can do without raw sockets.

The knock against Steve on this wasn't so much the initial panic about raw sockets, but that he stuck to his guns once people explained how this wasn't a big deal. Either he Just Didn't Get It, or he wanted to fearmonger, or both. He sounded a bit chicken little here, and never really seemed to get why he was wrong.

Winders XP Steve hates 8, fine, we all do. But instead of going to 7, for a long time he wanted to stick with XP. His reasoning, i don't go to any bad websites, i have a firewall, etc. This is shortsighted. Malware advertising on random ad networks is a big deal now, can Steve vet EVERY ad that he sees on the net? Can he vet that every website that he visit has never been pwned and had malware inserted? Can he vet that every machine on his LAN is clean? The worse thing is that he keeps talking about how he runs XP over and over on his podcast. He kind of implies "this is safe for me to do" but never really says "nobody else in their right mind should do this".

Assembly for a long time he was crazy about assembly, kind of showing how cool he was by using it. I learned assembly/machine code from a book when i was in 7th grade or so. I think it's cool in theory to write some assembly code now. in practice I'd never use it for a real app. Why not? Partially because of time; most libraries and tools are for C or other higher-than-assembly-level languages - you'd need to reinvent a lot of wheels and hope you did them right. And partially for static checking tools which would have a much harder time with assembly checks.

Mr Gibson's podcast has some good factual info, but his opinions are occasionally off and sometimes even dangerous. It's like the story of the broken watch - a broken watch is right twice a day, but you'd need another watch to tell you when. Steve's right a lot of times, but you need to know enough already to know when he's not right, and when he's not right RUN.

Can you please tell me where the passwords are in this memory dump ...

Have you ever seen a real exploited piece of data?
These are taken from Yahoo production servers, a day or two ago:

http://cdn.arstechnica.net/wp-...
http://cdn.arstechnica.net/wp-...

Can you guess where the password is, now? (And those didn't even take that many tries)

I have not seen actual SSL private keys floating around just yet, but given that the original researchers said they managed to get private keys from their own servers, I think it is reasonable to assume that some production servers must have already leaked them.

That's good post. I'm going to blatantly copypaste it because Theo gets to the crux of why Openssl is terrible:

From: Theo de Raadt cvs.openbsd.org>
Subject: Re: FYA: http://heartbleed.com/
Newsgroups: gmane.os.openbsd.misc
Date: 2014-04-08 19:40:56 GMT (1 day, 6 hours and 15 minutes ago)

> On Tue, Apr 08, 2014 at 15:09, Mike Small wrote:
> > nobody gmail.com> writes:
> >
> >> "read overrun, so ASLR won't save you"
> >
> > What if malloc's "G" option were turned on? You know, assuming the
> > subset of the worlds' programs you use is good enough to run with that.
>
> No. OpenSSL has exploit mitigation countermeasures to make sure it's
> exploitable.

What Ted is saying may sound like a joke...

So years ago we added exploit mitigations counter measures to libc
malloc and mmap, so that a variety of bugs can be exposed. Such
memory accesses will cause an immediate crash, or even a core dump,
then the bug can be analyed, and fixed forever.

Some other debugging toolkits get them too. To a large extent these
come with almost no performance cost.

But around that time OpenSSL adds a wrapper around malloc & free so
that the library will cache memory on it's own, and not free it to the
protective malloc.

You can find the comment in their sources ...

#ifndef OPENSSL_NO_BUF_FREELISTS /* On some platforms, malloc() performance is bad enough that you can't just

OH, because SOME platforms have slow performance, it means even if you
build protective technology into malloc() and free(), it will be
ineffective. On ALL PLATFORMS, because that option is the default,
and Ted's tests show you can't turn it off because they haven't tested
without it in ages.

So then a bug shows up which leaks the content of memory mishandled by
that layer. If the memoory had been properly returned via free, it
would likely have been handed to munmap, and triggered a daemon crash
instead of leaking your keys.

OpenSSL is not developed by a responsible team.

Basically, an attacker can connect to many secure Internet services - could be a banking website, or your email server, or a server hosting software updates, or possibly your corporate VPN - and learn everything that the server knows. This includes the private key (sort of like a super-complex and super-secret password) that is used to *make* the service secure. The attacker can then get all the data that the server sees, ranging from normal user passwords to all your emails and banking info.

This vulnerability is many, many kinds of bad. I'm simplifying a lot here. Basically, an awful lot of data is at risk right now, because of this bug.

This site has a pretty great explanation that most people likely to be found on /. will be able to follow, even if not normally security types: http://heartbleed.com/