Following the recent string of security-related kernel issues [story], the question was raised on the lkml what formal effort is being made to audit new patches. Long time Linux kernel guru Alan Cox [interview] noted two trends that he considers positive. First, that "tools like coverity and sparse are significantly increasing the number of flaws found", often finding flaws that have been in the code a long time. Second, Alan noted that security holes tend to come in bursts all related to the same type of problem. He explains, "if you plot things like 'buffer overflow' 'structure passed to user space not cleaned' 'maths overflow check error' against time you'll see they show definite patterns with spikes decaying at different rates towards zero." Alan added, "there are also people other than Linus who read every single changeset. I do for one."

Theodore Ts'o went on to point out that "most of the kernel vulernabilities that have been found are not remote execution vulernabilities, but privilege escalation bugs, or data leakage bugs (technically a security vulnerability but most of the time what gets leaked is truly boring) or denial of service bugs (yawn; there are enough ways of carrying out DOS attacks that don't represent kernel bugs)." He also added, "it's important to take statistical analysis with a huge grain of salt sometimes; but an increase [in] bugs found doesn't mean that the product is getting buggier; just that more bugs are happenning to get fixed."

From: John Richard Moser [email blocked]
To:  linux-kernel
Subject: Linux Kernel Audit Project?
Date: 	Mon, 17 Jan 2005 02:17:37 -0500

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is there an official Linux Kernel Audit Project to actively and
aggressively security audit all patches going into the Linux Kernel, or
do they just get a cursory scan for bugs and obvious screwups?
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB62aRhDd4aOud5P8RAnaYAJ9Erare1zWYUTJhdQlyrVaHZxtL5wCfWCCy
Eft5UL62EbiWHjivvbjaSmg=
=hies
-----END PGP SIGNATURE-----



From: John Richard Moser [email blocked]
Subject: Re: Linux Kernel Audit Project?
Date: 	Mon, 17 Jan 2005 02:40:06 -0500

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On the same line, I've been graphing Ubuntu Linux Security Notices for a
while.  I've noticed that in the last 5, the number of kernel-related
vulnerabilities has doubled (3 more).  This disturbs me.

I categorized the vulns I'd found into fairly arbitrary categories; upon
looking at a graph, I noticed that some bars were short and others were
unbelievably long (duh).  Reordering things, I came up with what looks
suspiciously like a standard normal distribution.

Kernel vulnerabilities appear to be falling within the first two
standard distributions now, at a glance.  95% of vulnerabilities land
here; 8.3% (kernel vulns excluding buffer overflows) fall within this
range, I'm guessing about . . . well, 8.3% chance.  Total I have 10% of
the vulnerabilities graphed as being from the kernel.

Every time a new kernel vulnerability is made (whether I see it or not),
that bar moves towards the center.  Every time a userspace vulnerability
is made, that bar moves outwards.  I can only graph what I can see, but
I'm very worried; if that bar keeps moving the way it's going, faster
than US vulns, then the probability of KS exploits is probably genuinely
increasing in probability.

Kernel space exploits can never be sanely protected against.  Even if
you can catch and kill them, you cause a system crash (major DoS), which
is hardly a good solution.  At least in userspace when SSP or PaX kills
something, the user either restarts it, or init is running it as a
daemon and just auto-restarts it immediately.  And at least it only
causes a small burp.

SELinux won't help either.  If you exploit the kernel, you're in.
Sometimes this is root access and you get lucky because SE doesn't know
who you think you want to be; other times this is arbitrary code
execution from inside the kernel and it doesn't matter who the kernel
thinks you are, you're in control.

Oh well, at least they still get fixed when they're seen.

John Richard Moser wrote:
> Is there an official Linux Kernel Audit Project to actively and
> aggressively security audit all patches going into the Linux Kernel, or
> do they just get a cursory scan for bugs and obvious screwups?

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB62vUhDd4aOud5P8RAlNDAJ91Om3VdcNXpHJ/Yamm9cG3JyYMugCfaSzb
Ngq2bR/PtAC+q0wASg5frng=
=xsfz
-----END PGP SIGNATURE-----



From: Alan Cox [email blocked]
Subject: Re: Linux Kernel Audit Project?
Date: 	Mon, 17 Jan 2005 12:23:35 +0000

On Llu, 2005-01-17 at 07:40, John Richard Moser wrote:
> On the same line, I've been graphing Ubuntu Linux Security Notices for a
> while.  I've noticed that in the last 5, the number of kernel-related
> vulnerabilities has doubled (3 more).  This disturbs me.

I've been monitoring the kernel security stuff for a long time too.
There are several obvious trends and I think most are positive

- Tools like coverity and sparse are significantly increasing the number
of flaws found. In particular they are turning up long time flaws in
code, but they also mean new flaws of that type are being found. People
aren't really turning these tools onto user space - yet -

- We get bursts of holes of a given type. If you plot things like
"buffer overflow" "structure passed to user space not cleaned" "maths
overflow check error" against time you'll see they show definite
patterns with spikes decaying at different rates towards zero.

There are also people other than Linus who read every single changeset.
I do for one.

Alan



From: Theodore Ts'o [email blocked]
Subject: Re: Linux Kernel Audit Project?
Date: 	Mon, 17 Jan 2005 13:16:52 -0500

On Mon, Jan 17, 2005 at 12:23:35PM +0000, Alan Cox wrote:
> 
> - Tools like coverity and sparse are significantly increasing the number
> of flaws found. In particular they are turning up long time flaws in
> code, but they also mean new flaws of that type are being found. People
> aren't really turning these tools onto user space - yet -
> 

Also, most of the kernel vulernabilities that have been found are not
remote execution vulernabilities, but privilege escalation bugs, or
data leakage bugs (technically a security vulnerability but most of
the time what gets leaked is truly boring) or denial of service bugs
(yawn; there are enough ways of carrying out DOS attacks that don't
represent kernel bugs).  The percentage of vulnerabilities which are
actually of the "browse a certain web page with Internet Exploder and
you are 0wned" are far fewer with kernel bugs, by their very nature.
That's not to say that such bugs shouldn't be fixed, but that unless
you're some hack from the Yankee Group getting paid by Microsoft,
there's no point to ring the alarm bells.

Finally, it's important to take statistical analysis with a huge grain
of salt sometimes; but an increase it bugs found doesn't mean that the
product is getting buggier; just that more bugs are happenning to get
fixed.  You need to do a lot more analysis to discover if this is due
to code analysis tools finding bugs in old code, or bugs being turned
up in newly modified code, etc.

							- Ted

• Archive of above thread
• KernelTrap interview with Alan Cox