Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Comments
Did A Faulty Memory Feature Lead To Heartbleed?
Newest First  |  Oldest First  |  Threaded View
macker490
100%
0%
macker490,
User Rank: Ninja
4/20/2014 | 6:55:13 AM
don't blame the tools
you don't blame the tools for sloppy work. heartbleed was caused by a crass violation of an old and well known programming standard: you don't let user input data control your program.  you control the input.  in this case the attacker submits a wrong length record -- stating he has a 64k payload and providing 1 byte -- and gets a slice of server memory as a prize. the stupid award goes to the programmer.

readers should note SQL injection is a similar problem --  letting a remote user send sql programming is a sure recipie for trouble -- and sql injection has been a favorite vector -- for years
1401
50%
50%
1401,
User Rank: Apprentice
4/17/2014 | 8:00:44 PM
Re: Memory management not the core issue
Aha - but imagine - if software developers and vendors had really accepted the wisdom of Multics and then the segmented memory architecture in the Intel 286 chip and beyond, memory bounds and memory typing would be handled by HARDWARE!!!!  BUT - once again, laziness - uniform addressable memory wanted for convenience sake - security and software quality - well, who pays for that, who really cares out there in the marketplace anyway - the atitude of the 1980s and 1990s now "coming home to roost".

I wonder - has anyone really gone back and looked closely at the reasons for those important computer architecture decisions based on solid computer science from the early 1980s?  (After all, Multics dates form the 1960s!) Add to that the ideas behind "madatory access control (MAC)" whereby unknown sofware of unknown provenance could NOT inherit ALL the privileges of the user, for example, downloading it from the Internet connected computers. 

AND then imagine any reputable software system vendor incorporating open-source software sub-systems, of critical security significance, into a product WITHOUT full "destructive" testing - I can, and they do!  The only choice, a Richard A Clarke has often put it is government to at last realise that the national information infrastructure is of national security importance and, like most other industries, solid and determined regulatory environments are needed before the industry will wake up and take note.  

Image if GM or Ford or Toyota or Volvo or - all car manufacturers - never crash tested their cars!  Imagine if there were no Federal Aviation Administration regulations covering aircraft and services!  Imagine no regaultions over pharmaceuticals and food!  Well - that is where we are with IT.
Kelly Jackson Higgins
50%
50%
Kelly Jackson Higgins,
User Rank: Strategist
4/17/2014 | 11:29:27 AM
Re: Memory management not the core issue
Thanks for the feedback, @EdMoyle. OpenBSD is doing an overhaul of OpenSSL in what they consider a security cleanup of the code. I'm not sure where all of this will go--there is a major cultural gap between the two groups of developers, it appears. My hunch is that there will be more security problems found with the code and it won't just be memory allocation issues as you note. The good news is that there is more scrutiny over encryption software, so in the end, it should get better. #optimist
Ed Moyle
50%
50%
Ed Moyle,
User Rank: Apprentice
4/17/2014 | 11:22:57 AM
Memory management not the core issue
First, great reporting Kelly as always.  

Second, I'm sure I'll get flames for this, but it strikes me that the mechanics of memory allocation aren't the issue here.  The lack of bounds checking (i.e. the bogus length sent to memcpy) woud still have been there no matter how the buffers in question were allocated.  

Yes, it's possible the read would have caused the call to segfault instead under a different set of circumstances (maybe, depending on architecture and where/how the buffer was allocated.)  It's also possible that certain values (e.g. keys) might have been cleaned up sooner under a different set of circumstances (again maybe, possibly, could be.)  But the core issue seems to me to still be the bogus length supplied to memcpy which isn't fixed no matter how buffers get allocated.    
RyanSepe
50%
50%
RyanSepe,
User Rank: Ninja
4/16/2014 | 4:41:19 PM
Performance over Vulnerability
I agree with Chris Eng that hindsight is 20/20 and I doubt very much that presented with the very simple choice of performance over, in this case vulnerability, would have been chosen by the OpenSSL project. I think the rest of the argument was short-sighted. Performance over security is plausible to some extent if not advisable. Are you going to have systems and methodology so locked down that availability becomes an issue, to the extent where it hinders business? It goes against all principles of the CIA triad. The statement that the OpenSSL chose this flawed memory allocation method knowing that dormant within was this extreme vulnerability is ridiculous. And if I am mistaken and this was known all along, then the people behind the OpenSSL project are maniacal and there is more pressing issues at hand.


COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
Omdia Research Launches Page on Dark Reading
Tim Wilson, Editor in Chief, Dark Reading 7/9/2020
Mobile App Fraud Jumped in Q1 as Attackers Pivot from Browsers
Jai Vijayan, Contributing Writer,  7/10/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15105
PUBLISHED: 2020-07-10
Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authenticati...
CVE-2020-11061
PUBLISHED: 2020-07-10
In Bareos Director less than or equal to 16.2.10, 17.2.9, 18.2.8, and 19.2.7, a heap overflow allows a malicious client to corrupt the director's memory via oversized digest strings sent during initialization of a verify job. Disabling verify jobs mitigates the problem. This issue is also patched in...
CVE-2020-4042
PUBLISHED: 2020-07-10
Bareos before version 19.2.8 and earlier allows a malicious client to communicate with the director without knowledge of the shared secret if the director allows client initiated connection and connects to the client itself. The malicious client can replay the Bareos director's cram-md5 challenge to...
CVE-2020-11081
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
CVE-2020-6114
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...