Haha. The Internet is now affected by worst vulnerability in the history of vulnerabilities, thanks to the freetard menace.

thanks to the freetard menace.

There should be a penalty everytime a company gets hacked. That way, there will be incentive for companies to avoid products that have a history of nasty security bugs (that is, products that rely on OpenSLL).

Now, companies just select the cheapest solution. And the customers get the shaft. And companies win the class action lawsuit.

Kurks,

You mean like reversing the responsiblity for "identity theft" which is really a loss of identity that a bunch of companies created for you, usually against your will (credit reports, etc.)? But YOU are ultimately responsible for? LAWL that will never happen. Corporations own the world, my friend.

The problem here, Kurks, is that it isn't "a company."

It's the entire methodology.

(If you've got a good solution to that, I'm honestly looking forwards to it.)

As a sidenote, what kind of sh!tty coding is this? Why do the buffer-length test and call memcpy every single time, instead of making a securememcpy() function that does these for you? I mean, this is an SSL library, there must be several places where buffers need to memcpy'ed securely, so the effort should be worth it.

I am in a university that is more known for it's Saturday night parties than the knowledge it disseminates, and even I know that much.

PS: Reminds me a project a fellow undergratuate had written, and he did list manipulation by doing the same things in multiple places, instead of taking one minute to write additem(), deleteitem() and finditem().

Easy solution. Ban freetardism. Make it a crime to provide source code to the public. Give Microsoft a de facto UN-sanctioned monopoly on OS and web server software much like utilities get monopolies. That's how we'll solve this nonsense.

instead of making = instead of writing

kurk,

That requires knowing the length of the data pointed to, which we know from C (which is another freetard invention) is who the f**k knows where in any given program. Certainly it is not stored logically with the pointer itself. That would make too much f**king sense for the freetards.

@ED

If you can do it inline (aka on the spot), you can do it in a function, or failing that, with a macro. Cheers.

As a sidenote, what kind of sh!tty coding is this? Why do the buffer-length test and call memcpy every single time, instead of making a securememcpy() function that does these for you? I mean, this is an SSL library, there must be several places where buffers need to memcpy'ed securely, so the effort should be worth it.

Good catch.  Indeed.  Recidivist C.  That's all there is to it.

Of course, all the apparatus behind this drivel ... no way would Microsoft or Apple or even Google miss that.

Only Freedom can let this crap in.

kurks,Yeah you could have a consistant way to store the length of the buffer. You can also use a language that is not a complete clusterf**k of insecurity to begin with. You could also not be a complete freetard writing open sores code only Hitler could be proud of. By bet is none of these three apply to any given freetard project.

Yeah you could have a consistant way to store the length of the buffer. You can also use a language that is not a complete clusterf**k of insecurity to begin with.

There's also the possibility that you could add a guard on the length, which is what these people would have done in a simple short routine.  Had they not been ignorant worthless cretins with no review.

Remind us all again, Queef, how that "Hello World!" program went.  As I recall, it didn't suffer from buffer overrun problems, did it? Just sheer incompetence.

Why don't you just shut up and leave it to the professionals?

Notice too, how they don't use descriptive variable names. What the f**k is a "bp"? British Petroleum? Would it hurt anything to use a few more f**king characters when you define variables? Remember this comes from the same people brought you such things like "etc", "usr" (whcih is not user directories, f**k knows what is actually suppose to be here), and "grep" (the f**k?). It's just layers upon layers of fail.

I'm not Queef. By the way, eat dicks DrLoser. Thanks.

Ed - Bitcoin miner, tireless defender of open source, supporter of OWS movement.

Is there one thing that this kid does that doesn't scream "I am young and impressionable"?

Notice how the resident idiots go off on douchebag tangents instead of focusing on the topic.

should I be a dumass you never wrote a line of code and say that we should be using languages that lessen the chance for these kinds of things in the first place.

But carry on. People know that only pussies use those languages and real manly stuff needs to be written in C.

There should be a penalty everytime a company gets hacked. That way, there will be incentive for companies to avoid products that have a history of nasty security bugs (that is, products that rely on OpenSLL).

Sysadmins of these companies tend to be raging neckbeards who believe s*** like this.

So far, OS X has not fallen prey to any major, automated attack like the MyDoom virus. There are several reasons for this. One is that OS X is based on open source software such as BSD; many hackers have searched this software over the years looking for security vulnerabilities, so that not many vulnerabilities remain.

The problem is not the lack of dictatorial measures that punish poor code. It's the morons that perpetuate the *nix/FOSS security myth.

Oh, cmon, that mistake could happen to anybody. TBH, I feel for the poor motherficker, (s)he will get enough sh3t anyway.

I think you must place the blame on the freetard/open source crowd: after all, what happend with the 'given enough eyeballs, all bugs are shallow' thing? I thought when the source is published, everything is automagically perfect. :) 

Oh, cmon, that mistake could happen to anybody.

This is exactly why you are never going to hear witty names, e.g. "The Spring of TLS Bugs", from the media or the blogosphere. Like the American anti-trust law, a stated double-standard is openly applied.

Taking all the above into account, I think Kurks has hit the nail on the head best.  It beggars belief that the writers of a so-called "security" module wouldn't be paranoid about raw memory copies; I mean, is trivial static analysis too much to ask?

Naturally, it also beggars belief that the corporate consumers of a security module don't bother to run an audit over the (free open super sauce!) code.  Red Hat should be publicly disgraced for this negligence.

The fact that everyone from Cisco to Avaya use OpenSSL (even though their products used the older version and were not affected) too and they are too cheap to hire eyeballs to audit the code means one thing. Major tech corporations don't give a s*** about security. That or they are too stupid to believe in the MillionEyeBalls.