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
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
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
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
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
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
Improving Enterprise Cybersecurity With XDR
Enterprises are looking at eXtended Detection and Response technologies to improve their abilities to detect, and respond to, threats. While endpoint detection and response is not new to enterprise security, organizations have to improve network visibility, expand data collection and expand threat hunting capabilites if they want their XDR deployments to succeed. This issue of Tech Insights also includes: a market overview for XDR from Omdia, questions to ask before deploying XDR, and an XDR primer.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2022-2339
PUBLISHED: 2022-07-07
With this SSRF vulnerability, an attacker can reach internal addresses to make a request as the server and read it's contents. This attack can lead to leak of sensitive information.
CVE-2022-20752
PUBLISHED: 2022-07-06
A vulnerability in Cisco Unified Communications Manager (Unified CM), Cisco Unified Communications Manager Session Management Edition (Unified CM SME), and Cisco Unity Connection could allow an unauthenticated, remote attacker to perform a timing attack. This vulnerability is due to insufficient pro...
CVE-2022-20768
PUBLISHED: 2022-07-06
A vulnerability in the logging component of Cisco TelePresence Collaboration Endpoint (CE) and RoomOS Software could allow an authenticated, remote attacker to view sensitive information in clear text on an affected system. This vulnerability is due to the storage of certain unencrypted credentials....
CVE-2022-20791
PUBLISHED: 2022-07-06
A vulnerability in the database user privileges of Cisco Unified Communications Manager (Unified CM), Cisco Unified Communications Manager Session Management Edition (Unified CM SME), and Cisco Unified Communications Manager IM & Presence Service (Unified CM IM&P) could allow an auth...
CVE-2022-20800
PUBLISHED: 2022-07-06
A vulnerability in the web-based management interface of Cisco Unified Communications Manager (Unified CM), Cisco Unified Communications Manager Session Management Edition (Unified CM SME), Cisco Unified Communications Manager IM & Presence Service (Unified CM IM&P), and Cisco Unity ...