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.


Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Data Breaches Affect the Enterprise
Data breaches continue to cause negative outcomes for companies worldwide. However, many organizations report that major impacts have declined significantly compared with a year ago, suggesting that many have gotten better at containing breach fallout. Download Dark Reading's Report "How Data Breaches Affect the Enterprise" to delve more into this timely topic.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-3802
PUBLISHED: 2021-11-29
A vulnerability found in udisks2. This flaw allows an attacker to input a specially crafted image file/USB leading to kernel panic. The highest threat from this vulnerability is to system availability.
CVE-2021-39995
PUBLISHED: 2021-11-29
Some Huawei products use the OpenHpi software for hardware management. A function that parses data returned by OpenHpi contains an out-of-bounds read vulnerability that could lead to a denial of service. Affected product versions include: eCNS280_TD V100R005C10; eSE620X vESS V100R001C10SPC200, V100R...
CVE-2021-43691
PUBLISHED: 2021-11-29
An unspecified version of tripexpress is affected by a path manipulation vulnerability in file system/helpers/dompdf/load_font.php. The variable src is coming from $_SERVER["argv"] then there is a path manipulation vulnerability.
CVE-2021-43692
PUBLISHED: 2021-11-29
An unspecified version of youtube-php-mirroring is affected by a Cross Site Scripting (XSS) vulnerability in file ytproxy/index.php.
CVE-2021-43693
PUBLISHED: 2021-11-29
vesta 0.9.8-24 is affected by a file inclusion vulnerability in file web/add/user/index.php.