Heartbleed, Running the Code - Computerphile 

I'm not like a pro yet but from my experience some complex or more secure apps do have variables named like this. Idk id guess it's security over readability maybe? And I'll say it's always easier to understand a vulnerability after they happen rather than before. Seems so simple to us but who knows what they were thinking. Or maybe the complexity with the variables actually caused the issue lol

@@patrickconrad396 Security by obscurity isn't really security. It's probably because for people who write this kind of codes, it's kinda obvious. p = pointer, bp = buffer pointer, pl = payload length But i also don't like those short namings.

@@mutzikatzi1 Totally agree

Yes. We are never supposed to trust the client

I found that to be the case in most of the web. Because of this, this is why myspace worms break out. With all websites trusting eachother, you can do SQL Injection and XSS.

You are, indeed, correct. It is always best practice to check if an email field fits the pattern *@*.* or that a password field is at least 6 characters in length or, if you're accessing a database, that your table variable has greater than 0 rows. Not only does it prevent unforeseen error messages, it prevents an exploit such as this.

I as a programmer am deeply baffled how one could make such kind of error - the level of absolute incompetence is just staggering (programmer/s + QA). It is not even hidden under layers of other code! No validation of external data in security critical code!? Amazing.

You are completely right, but as a programmer I want atleast to explain, how bugs like this can occur: If you are writing several thousand lines of code, it is rather likely to forget the checking processes for the data at one point or the other. And it's even more likely for something like this to happen, if you are coding protocols. (As network protocols usually need to be as performance-efficient as can be and therefore you try to accomplish your goal in general with as few lines of code as possible.)

This is literally the first lesson we learned in computer science classes beyond the basic "Intro to Programming" course; namely, don't trust the end-user. Assume they are either 1) a complete idiot who won't use the software correctly or 2) a malicious user who will exploit your program if possible. NEVER EVER trust data sent from a user without performing sanity checks and validating it

***** you mean lpfstrHW doesn't tell you anything? ;)

Ip from string ...hardware?

+Felype Rennan Nope.

I agree that Java can't contain C code, but C# allows for unsafe native code, yes, usage of native libraries and there is C++/CLI as well. And naming conventions, they could name things well in the C standard libraries, like pascal guys used to do, but, they just chose to not.

+CaptainDuckman Hungarian Notation, the idea is that you include the type of every variable in its name. It makes it more obvious if you are using the wrong type.

Despicable that bugs like this are getting through in the very part of the system designed to be extra secure.

CelmorSmith I believe it was purposely put in there on the behest of government agency. Its seems like a very obvious mistake. This is first year university level logic mistake. Like a situation where the lecturer makes very elementary flaws in the code and students are given 15 min to correct it. As another poster mentioned that not being someone from a programming background even he could see the inherent logic flaw. That is, trusting data sent WITH OUT VERIFYING IT. This is utterly unheard of in any programming practice. So this to have escaped professionals designing security... is highly suspect to say the least. I think you have to include more people then we think in to the "bad guys" group unfortunately. Some of those who run forces are the same who burn crosses ~ RATM

It has been known about for years, as with lots of bugs academics and industry experts are aware of many of these but it simply too costly or not seen as worth fixing unless there is a known or presumed risk. You must remember that the majority of the population are extremely lazy and uneducated in the ways that computers work - and really that is how security is maintained.

Strings don't have a length parameter.

Say the next 6 letters: Badeth haha Would be the same as Say this: Badeth

@@natnew32 Yes, and string isn't even a data type in C, they're just an array of characters.

Short answer: No. Long answer: The computer has no way of telling where an arbitrary sequence ends, unless it uses some sort of terminator value or a predefined size placed in front of the sequence.

clearly there is a way to tell the actual size of the payload since it was needed to apply the patch. the entire issue was caused because the code didn't check if the actual length of the payload matches the integer value provided by the client.

How many processor cycles would it take? When you would do that to every variable in your code.

That's the University of Nottingham Jubilee Campus, home to their Computer Science building :) >Sean

***** Thanks Brady, I'll have to check out that campus!

+Sean Haggard Looks a lot like York's new place. Very similar to Nott's obviously.

checking if the payload is the length specified by the user would suffice. Sth. like "if(payloadLength == payload.Length)" (but i'm not a C programmer) would be enough if the container has that method. But finding out the Length would be with that Method easier anyway.

I like the scene with the Ducks.

Faked filename, but the spelling mistakes help you zero in on it.

Yes, because searching for the filename on the screen may be too hard, huh?

Searching for the filename is only for hackers, not regular users LOL

The uncompiled code is available on Symantec's, Security Focus website. has been for years. Along with a whole lot more. It's what security research is all about

Even without searching the filename, it wouldn't be too hard to make considering they showed you how to make a heartbeat packet.

Tom Scott also did a great one on his own channel.

no.

You'd be surprised by how most bugs come from there. Sometimes, it's not the user but the "evil programmer": Sometimes it's functions in kernel-space not being prepared for evil arguments which make them write where they shouldn't, and these turn out to be used to make root exploits, etc.