Here is some new bad news, and i mean really bad news

Only if you're dumb enough to use Yahoo, gmail, or any Micro$hi

No, openSSL is open source, as in facebook, google, xxx (you name it) linux servers.

I never trusted public web mails and ATM machines. Now i have to stop using everything on the web

Here is the technical analysis:

And some details:

which reinforces what an astonishingly bad programming language c is.

See Link:

?;..((

There is absolutely NOTHING wrong with C. The original designers - Ritchie/Kernighan created a language, often called "souped up Assembly" to do system-level tasks. Incompetent programmers cannot pass on their stupidity on some computer language. Please try finding out why Yahoo or later Bing could not come remotely close to Google in terms of search speed performance.

The PDP-11 architecture is plainly visible in c. As is the early PDP-11 programming style, all that wandering about with autoincrement/autodecrement pointers and variable-typing hazards.

Ancient, barbaric, and dangerous.

?;..((

This is the best illustration of the flaw I have seen - thanks for that link.

That just reinforces what an astonishingly poor understanding you - and many others - have about programming languages, and about bugs in software.

This was a bug in the implementation of the response to "heartbeat" telegrams in OpenSSL, which is a commonly used library for SSL. The bug was caused by the programmer using data in the incoming telegram without double-checking it. It is totally independent of the programming language used, and totally independent of the SSL algorithms and encryption.

It is possibly arguable that the recent "goto fail" flaw in Apple's code is due to C syntax, but even there the main error was poor development practices and poor use of static error checking tools (i.e., if the developers had enabled the compiler's warnings and checks, the bug would have been found immediately).

Some types of security errors and bugs turn up more often in C programming than when working with more "managed" languages, and it is certainly easy to write code with memory leaks, buffer overflows, etc., in C. But in this case, it was a design flaw and could have been made just as easily in any language.

This is really a problem of the go

(ghost key pressed)

This is really a problem of the Government/Industrial leadership (or lack of). This could have been fixed quietly with must less damages. But now, everybody (including criminals) know how to and how easy it is to hack into servers.

If someone discoveres a bug, who are you going to call? NSA, CIA, FBI, etc?

Unchecked buffers and stack overflows have been chronic security lapses for decades now, thousands and thousands of times. Wandering around data structures with autoincrement pointers is like stumbling in a mindfield, blindfolded. With various-sized mines.

The c language and, more significantly, the c language culture, will make this sort of thing keep happening.

Data should be stored in declared buffers, and runtime errors thrown if attempts are made to address outside the buffer. Items should be addressed by named indexes, not by wandering around with pointers.

And it's crazy for compilers to not use MMUs to prevent data and stacks and code from being all mixed up.

Given the compute horsepower around these days, most programmers should be running interpreters, Python-type things, that can protect the world from the programmers.

ADA has better protections than c, but requires discipline that most programmers don't have time for.

There is already something like that: server side Java. But think for a moment how that would impact performance of servers with hundreds and thousands of clients. For servers, every bit of performance count.

Remapping MMU hundreds or thousands times for every program? Impractical!

But the heartbeat problem has nothing to do with bufferoverflows etc. The programmer did just not check (for whatever reason - there are a lot of rumors spreading how this could happen) whether the information coming in makes sense.

This has nothing to do with C or any other programming language. Rather with bad design. Worse it seems to be a blow to the open source community, which always claimed their code is better/safer than commercially developed software, because everyone can and will check the code. This did obviously not happen.

Actually the opposite is true. In order to become a capable C programmer you learn that it is your responsible to make sure that your code behaves well, when fed with garbage. Other languages tend to foster programmers less aware of what could happen and how an attacker might exploit weaknesses.

Actually I would claim that the majority of security problems is caused by those interpreters. Do I have to mention Java(-script)?

ADA has been responsible for the "most costly software failure of all times" - the Ariane 5 disaster.

Klaus

Reliable, secure code? Impractical!

It was an unchecked buffer bug. Just past the assumed but unchecked buffer was whatever else happened to be in memory. That sort of blunder has been chronic for decades, should be impossible, and keeps happening.

There was, in the DOS days, a joke circulating that a certain JPEG file contained a virus. A few years later, in Windows, Microsoft actually made that possible. Same problem, trusting that a declared size was the actual size of a structure, and data and code and stack mixed in the same memory spaces.

A strongly typed language without pointers, and with runtime bounds checking, and compilers that use proper protections, would prevent sloppy errors like this one.

You're joking, right? The trickier the language, the better the programmers?

ADA wasn't responsible. If someone converts a float to a 16-bit integer, to do something like load a DAC maybe, he is obligated to consider the consequences. That's true in any language.

At least nobody died.

The technology is already there, but at what cost? What you are saying is really putting JVM like sand boxes on all servers. Performance hits could be 70% to 90%, on my conservation estimate.

Actually, it was, with all the interested parties warned before it was made public, to allow servers top be patched.

It's really not as bad as the hype anyway.

In fact, this bug is simply the result of a malloc() requested chunk of memory only being partially filled by the requesting application before being sent back to the remote requesting node, the remainder of the buffer containing what malloc() returned.

This site had an update:

where Cloudflare tried to access sensitive info using this method and got garbage.

It's not surprising. Assuming the server has 32Gbytes memory, the buffer size 64k, then you have a possible 512,000 x 64k blocks to examine. Also, to find out where the sensitive data is, you first have to discover the code / process that was using it to find the location, which means disassembling the code, always assuming that you can find it. Also, in a virtual memory environment, both code and data could be fragmented all over physical address space, or the memory could have been reallocated or overwritten. All in all, not a trivial task, even for the security services with all the resources at their disposal.

Summary: Storm in a teacup :-)...

The PDP-11 separated code, stack, and data spaces. A stack overflow made a hardware trap, it didn't clobber code space. Code space was execute-only and could not be written by the application running it. Data pages could be r/w or read-only. All that in the 1970's.

C, or at least most c compilers, tangle code, data, and stacks so much that MMU protection is not feasible. A pointer can clobber anything... bytes, longs, floats, other pointers, stuff on stacks, opcodes.

Buffer and stack overflows, and unchecked buffers, have been chronic security problems for decades. The language should prevent it; the culture should routinely check it. It's disgraceful.

We have a checklist for PCB layouts. Why don't programmers have a checklist for code?

So how to protect against this threat? I just got an email from a friend's yahoo address, saying that this person had been in an accident and needed me to send $1300 to a western union in Rome, Italy. All false of course. What to do? - practical steps? tia j

Working in c, always check every buffer for size errors. Study every pointer. Don't just write the code, READ it. Comment heavily, because commenting is a code review of sorts all by itself. c is of course a mostly write-only language and the culture discourages comments.

Or program in a better language, that simply doesn't allow data, or programming errors, to create system-level hazards.

The CS departments of the world should have Manhattan-project, Man-on-the-moon scale projects to make computing reliable. They have other priorities.

Rome,

Do you have your friends linked with social media like google+, facebook, t witter, linkedin, etc? People in some countries have plenty of time and mo tive to find links in social media. Social media is fun, but really danger ous. I stay away from them and people should be more careful using them. No wonder social media stocks are crashing.