Not just websites hit by OpenSSL's Heartbleed – PCs, phones and more under threat

Re: Cardiac Arrest

Presumably my Windows Phone is immune from this on the phone end at least!

Debug malloc

For most apps it's bound to be a useless waste of time, but I wonder how many security bugs in OpenSSL itself may have been prevented by always using a secure malloc.

@Neoc - Nuke the memory

That was my first thought, but then I read the detailed code analysis linked to in the article. The 64K sent back is copied from the attacker's payload. As the attacker's payload is only one byte, the rest comes from whatever is in process memory after the received payload.

malloc() on your platform might, but openSSL have their own wrappers around it, and cache the allocations before calling down to the O/S, so it neatly sidesteps that protection.

re: Never understood why malloc ... didn't nuke the memory area by default

Your forgetting that it is only in comparatively recent times that CPU cycles have been plentiful on some systems. Zero'ing memory was a nice to have but impractical outside of the test lab when workstation cpu's typically ran at sub 12.5MHz...

why malloc doesn't nuke

It's because it serves no purpose to do so.

An OS will certainly zero pages before giving them to you because those pages could have come from almost any previous process and the security implications of that have been known since the 60s. However, all sane runtime libraries ask for big blocks from the OS and then implement their own sub-allocation scheme on top. Doing it in-process is a big performance win (because you don't have to cross privilege boundaries) and omitting to zero the sub-allocated memory in your own address space is not a problem because it was already visible to any thread in your address space. It's not a problem until you then squirt the dirty memory out of a socket.

Yes, it could have been avoided by using calloc() rather than malloc() everywhere, but it could also have been avoided by sanitising your inputs before responding to them. The former would pointlessly double the number of writes to memory. The latter is simply "correct". My vote goes for the latter.

Note also that debug versions of malloc nearly always do pre-fill the memory (and the matching version of free post-fills with a different pattern) but this is *because* it is pointless to do so. Or rather, because it bloody well ought to be pointless and therefore doing it is a simple way of flushing out a certain class of bug.

In my view seeing a naked memcpy call at all in supposedly secure code is like walking into a restaurant kitchen and seeing a big pile of rotting carrion on the floor. The staff may know not to handle it before dipping their fingers in the gravy, but it's a clear danger that you don't want to have around. It may cost to clear it up, but that's what you have to do.

memcpy is a big red flashing warning light that says "make damn sure you've checked and sanitised every bit of data that goes in and out of here" (not only memcpy, of course, but quite a few other C functions). In fact. I'd suspect simply looking for all the memcpy et al. calls is a pretty good way of finding vulnerabilities. The best approach is to wrap them up pretty tightly. Even that's not 100% secure, but it does make a difference and in security code it's 100% worth doing.

Re: Windows XP

What's the point of having a drop-dead end-of-life support date if you keep trying to resuscitate it with another 'one last patch'?

Re: Windows XP

OpenSSL is not tied to Windows XP. It's a 3rd party component and I'd be surprised if anything shipped with Windows XP relied on the Win32 CryptoAPI.

Re: Few clients are vulnerable

>IE, obviously, isn't vulnerable

Just because it doesn't use OpenSSL libraries doesn't mean it isn't vulnerable to this attack vector.

Not knocking MS, but it is worth noting that without testing we don't know if third-party (ie. non-OpenSSL) SSL implementations are vulnerable to this attack. Otherwise good comment so up voted.

Re: Even worse than I thought

The OpenSSL vulnerability/exploit shows why you don't use the same physical hardware to handle the encryption/decrypt of data streams with different levels of security.

Key length is irrelevant to this, if the key is in memory then it is possible to grab it.

Re: Who Still Uses Malloc?

People still use malloc because it's faster. Especially in embedded systems (where OpenSSL is also used quite frequently) this can make a difference. Besides this: many libraries don't use malloc for every allocation, they keep a memory pool available. One would have to call memset every time to clear that data, which is unnecessary in any well-written library or application.

Re: Who Still Uses Malloc?

But is there a point in using calloc()?

The recipient still has to return the data to the sender and as far as the recipient is aware it's the stuff that's in the memory at the time. So whatever happens you are going to clear a buffer somewhere and then still return the wrong data because the recipient doesn't know, other than by the length byte, how long the data to be passed actually is.

The problem is the protocol which suggests that something can be defined by the sender. In the earlier days of the friendlier internet (remember the days when we could ping a domain to find all the eMail addresses before that was abused in the late eighties?)

The whole thing needs to be examined from top to bottom, re-specified and re-coded.

Re: The real bug

No, the real bug is having a software development system that allows someone with insufficient experience to add code to a system that needs to be secure - and then not having a sufficiently robust review process in place - and then installing that software in a critical situation on huge numbers of servers around the world.

This bug is the sort of mistake beginners make (I believe the culprit was still at uni). I'd be embarrassed if I put a bug like that into a one-off throw-away lash-up. But somehow it got into openSSL which everyone regarded as secure.

It's a bit like the debt-laundering that took place before the financial crash. Everyone thought the debt was solid, but simply because no-one bothered to look at the fundamentals. I think this incident has shown FOSS security to be based on similar principles.