Exploiting Linux kernel heap off-by-one
cyseclabs.com
Exploiting Linux kernel heap off-by-one
1–10 of 11 posts
Re: Exploiting Linux kernel heap off-by-one
#2When you see something like this:
/* args points to a PAGE_SIZE buffer, AppArmor requires that
* the buffer must be null terminated or have size This is a problem that comes up repeatedly in the Linux kernel. When some kernel call accepts or returns variable-length data, the details are handled locally, not in some general-purpose functions for moving variable-sized data in and out of the kernel safely. That's likely to lead to some checks not being made.
Re: Exploiting Linux kernel heap off-by-one
#3Ubuntu vulnerability list:
https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2...
(TL;DR: Ubuntu 16.10 (Yakkety Yak) is listed as "needs triage", no other releases are affected (14.04/16.04/etc))
Re: Exploiting Linux kernel heap off-by-one
#4Ubuntu vulnerability list: https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2... (TL;DR: Ubuntu 16.10 (Yakkety Yak) is listed as "needs triage", no other releases are affected (14.04/16.04/etc))
Actually, Ubuntu 16.10 is listed as not-affected (4.8.0-11.12).
The "needs triage" you're seeing for Ubuntu 16.10 is for the "linux-goldfish" and "linux-flo" kernel packages for specific android devices.
Re: Exploiting Linux kernel heap off-by-one
#5I've always wondered - what are the most (in)famous buffer overflow exploits? Heartbleed is one of the most popular ones I guess.
Re: Exploiting Linux kernel heap off-by-one
#6When you see something like this: /* args points to a PAGE_SIZE buffer, AppArmor requires that * the buffer must be null terminated or have size you just have to expect exploits. This is a problem that comes up repeatedly in the Linux kernel. When some kernel call accepts or returns variable-length data, the details are handled locally, not in some general-purpose functions for moving variable-sized data in and out o…
Nitpick: it's an internal kernel function being called by another kernel function, not a user-kernel interface.
What you seem to want is a general-purpose string implementation for shuffling data around. With a safe append() preferably.
Re: Exploiting Linux kernel heap off-by-one
#7I've always wondered - what are the most (in)famous buffer overflow exploits? Heartbleed is one of the most popular ones I guess.
Heartbleed isn't a buffer overflow in the classic sense (you're not writing more to a buffer than it expects to receive), it's just that you could set read buffer sizes that you shouldn't have been able to in a sane world. In that sense it wasn't even a "bug" (the software was doing exactly what the programmer intended), just a badly-specified protocol to begin with.
Re: Exploiting Linux kernel heap off-by-one
#8I've always wondered - what are the most (in)famous buffer overflow exploits? Heartbleed is one of the most popular ones I guess.
The Morris worm is literally the grand-daddy when it comes to buffer-overflows:
https://en.wikipedia.org/wiki/Morris_worm
After that you could see something like SQL Slammer as having a significant impact:
https://en.wikipedia.org/wiki/SQL_Slammer
But from a technical perspective most of them are much of a muchness - I'm more interested in the first time "things" were written up, such as "Smashing The Stack For Fun And Profit":
http://insecure.org/stf/smashstack.html
Or the first time that Format string attacks were documented - a whole class of vulnerabilities sprang up overnight (my memory is that wu-ftp was the original target there).
Re: Exploiting Linux kernel heap off-by-one
#9I've always wondered - what are the most (in)famous buffer overflow exploits? Heartbleed is one of the most popular ones I guess.
[deleted]
Re: Exploiting Linux kernel heap off-by-one
#10I've always wondered - what are the most (in)famous buffer overflow exploits? Heartbleed is one of the most popular ones I guess.
The Morris worm is literally the grand-daddy when it comes to buffer-overflows: https://en.wikipedia.org/wiki/Morris_worm After that you could see something like SQL Slammer as having a significant impact: https://en.wikipedia.org/wiki/SQL_Slammer But from a technical perspective most of them are much of a muchness - I'm more interested in the first time "things" were written up, such as "Smashing The Stack For Fun A…
> The Morris worm is literally the grand-daddy when it comes to buffer-overflows.
In 1988!