TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Further hardening glibc malloc() against single byte overflows

131 pointsby scarybeastabout 8 years ago

5 comments

alexfooabout 8 years ago
&gt; Now, if the attacker has an off-by-one corruption with a small value (NUL or \x01 - \x07) that hits the lowest significant byte of a length (malloc_chunk-&gt;size), the attacker can only use that to cause the length to effectively shrink. This is because all heap chunks are at least 8 bytes under the covers. Shrinking a chunk&#x27;s length means it will never match the prev_size stored at the end of that chunk. Even if the attacker deploys their one byte overflow multiple times, this new check should always catch them.<p>Is the LSB of the heap chunk size always &gt;= 8?<p>What about a malloc_chunk-&gt;size with a multiple of 256? (Or anything else with an LSB &lt; 7). With a one byte overflow one of this they could cause it to think that the size is up to 7 bytes more than the size of the real chunk.
评论 #14365428 未加载
评论 #14365366 未加载
loegabout 8 years ago
Couldn&#x27;t you trivially harden against single byte overflows by just changing your malloc implementation to add one to the requested allocation size?
评论 #14364066 未加载
pjmlpabout 8 years ago
Yet another patch on the Swiss cheese of memory corruption, with very little impact on future CVE database entries.
pussypusspussabout 8 years ago
Now this is what I want to see more of on HN.
评论 #14364378 未加载
faragonabout 8 years ago
Just write programs without overflows, and malloc() will not be a problem.
评论 #14365822 未加载