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

I think the social media market is crashing because the subscription lies are coming out (44% of twitter accounts have never tweeted). No problem. The IPO is over and the suckers now own the pig, lipstick and all.

rson

in Rome,

, twitter, linkedin, etc? People in some countries have plenty of time and motive to find links in social media. Social media is fun, but really dan gerous. I stay away from them and people should be more careful using them . No wonder social media stocks are crashing.

And I go on facebook to play poker only. Don't post any real data. Can't believe people are posting so much personal data for scamer to harvest. I have no friend on facebook. I am anti-social.

After what I've seen happening with the security agencies that we are suppose to trust, I don't discount foul play.

I too, do C/C++ programming and that sort of bug to me is not accidental.

I can think of only one reason to have an additional buffer length in the message package and have the software ignore the primary buffer length.

The problem here is, the OpenSSL should of tested for that from day one or totally ignore any data in the buffer for size parameters.

Sorry, sounds a little fishy to me.

Jamie

Well, if you want to talk to the ones that may have had something to do with it, go ahead, call them.

Jamie

I've never been on Facebook, though my wife keeps up with the family there. I can't believe people post pictures of their vacation, real time. "Dumb" doesn't even begin...

The heartbeat query could have had a fixed-length payload; 4 or maybe 8 bytes would work fine. Heck, one byte would work fine, just a local variable, no malloc at all.

malloc is evil.

You would have thought with the consequence of stack overflow being so great, and with the desired improvement of safety in various environments such as automotive, that a hardware stack MMU that only allowed certain instructions to write to stack would have been implemented by a semiconductor manufacturer. That might mean separate stack and heap areas, but can't be beyond the wit of man to implement that.

Having a checklist is one thing, but it's difficult for a third party to check someone else's code. I don't know if there are means to check if code is say MISRA compliant after the event?

iAPX432 tried to use it, IBM AS/400 used it by dividing programs into objects with separate MMU access.

Similar results can be used with libfence style tools, in which an inaccessible virtual memory page was inserted after each malloc allocation (and possibly before a stack segment). If the program went past the allocated space, first nothing happens, but trying to access the next virtual memory page, a page fault would occur, which then could be trapped.

Similarly inaccessible pages could be used between each stack frame.

The virtual memory consumption would not be a big deal, but the physical memory consumption, since even a single byte malloc would always require a full virtual memory page (4 KiB). Unfortunately C (and especially C++) seems to generate a huge number of small memory allocations and stack frames, thus consuming a lot of physical memory.

Unfortunately, the early x86 models had proper memory protection only at segment register level (not on individual virtually memory page level). Thus, the virtual page mapping described below, would not have been very effective on earlier x86 processors. The segment registers are used (all set to 0) in the x86 even in virtual memory paged systems.

Some, but not all PDP-11s had separate I/D Instruction/Data spaces, but were supported only on some OSs such as RSX-11M+ (but not in RSX-11M). A data access could refer to the static/dynamic as well as stack memory even in I/D mode enabled.

Any real HW protection was possible, as long as on of the 8 APR (Active Page Register) registers did not use the full 8 KiB. This was the case, if the last APR/APR were not used, so any stack wrap below 0 would be detected (both in single or I/D mode), if the stack was sitting in the low memory, such as in Fortran. For other languages, such as Pascal, with the stack in the address space growing downwards and the top APR set to expand downwards, a stack overflow could be detected, if the stack APR addressed less than the full 8 KiB.

However, since programs were often larger than 64 / 128 KiB, overlaying would be used, making it impractical to leave gaps between memory areas addressed by different APRs.

Only eight 8 KiB segments could be separately protected.

Only proper virtual memory systems, such as the late 70's VAX/VMS with

Even with early x86 processors, the OS makers could have at least used a different CS base address and allocate the code to different virtual memory area and hence effectively use the segment specific protection bits to avoid code overwriting.

Not 100% true. Extending your bar analogy a bit further, it's also a place for friends (and family) to meet.

Yes, e.g. PCLint.

Cheers

Phil Hobbs

K&R wrote the best book on a computer language ever: the C Programming Language. It's beautifully written; so clear and precise in every respect - a rare achievement in a technical work.

I don't think that helps. You can study and study and study a chunk of code over and over and over again and still not see where a possible problem lies. Computer Guru extraordinaire Steve Gibson (grc.com) has warned programmers about this phenomenon many times. Our thought processes simply don't work that way.

I don't go near any of it. The people who have the most to say about themselves are the most vacuous, self-obsessed, narcisistic, boring and uninspiring of individuals; well worth avoiding having any contact with.

At least in a bar you can see for yourself if the other person is of the age, sex and race they claim to be. Online you could be communicating with *ANYBODY* - a scary thing to contemplate. Social meja is a scammer's paradise.

This scare seems wonderfully well-timed to coincide with Widows XP support stopping. Some ruse to panic people into upgrading to Win8, possibly? Just a guess.

It is much wider spread than that. It impacts over half of web sites that use https, ssl, or tls for secure communications and allows for massive snooping. Read some more on heartbleed.

?-)

if attempts

named

moment how that would impact performance of servers with hundreds and thousands of clients. For servers, every bit of performance count.

stacks and code

Impractical!

Actually on any server that is used much the MMU is partially remapping thousands of times a second to 10,000s of times a second, the caches even more so.

?-)

software.

bug

without

encryption.

for

structures

blindfolded. With

make this

attempts

named

and code

be

from the

programmers

Wrong on both counts. C has more and better tools than Ada. In unix/linux and C their use is optional and clearly beneficial. In Ada their use is mandatory and not so clearly beneficial.

?-)