-----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-----
John Richard Moser <nigelenki <at> comcast.net> writes:
> 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?
>From a user point of view , there is at least tracking: patches are signed and
approved by the "component" maintenair before reaching mainline.
On Mon, Jan 17, 2005 at 02:17:37AM -0500, John Richard Moser wrote:
> -----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?
There were at least two such projects that crashed and burned
that I recall, the last was "active" about 3 years ago, and
accomplished very little.
Dave
-----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-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Damn that sucks. I think stable releases need every patch audited
before they get Linus' blessing, and unfortunately it seems we don't
have the required 150+ people jumping up to volunteer. :(
Yes I have unrealistic goals. Sane, but unrealistic. Perhaps
collaboration with the major distributions to volunteer developers to do
the auditing? We need SOMETHING; there's been too much line noise here
about kernel security holes. Whether this is new or people are just
noticing and overreacting now, it's still not good.
Unfortunately, "Something" requires manpower. Manpower requires people
who aren't busy doing other things, like improving preemptiveness,
rewriting the VM system, enhancing the scheduler, or writing new
drivers. And unfortunately, not only is everyone busy with all of that;
but we NEED all of that too.
Well, maybe you can't start up a group now, or implement audit policy;
but perhaps the invitation needs to be there. I see there are no -audit
or -security lists on vger; perhaps somebody should start a
linux-kernel-audit@vger list just to get the ball rolling. If it grows
big enough, then you can consider some policy about having the changes
audited FIRST before releasing; for now that's just not feasible.
Dave Jones wrote:
> On Mon, Jan 17, 2005 at 02:17:37AM -0500, John Richard Moser wrote:
> > -----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?
>
> There were at least two such projects that crashed and burned
> that I recall, the last was "active" about 3 years ago, and
> accomplished very little.
>
> Dave
>
- --
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
iD8DBQFB622KhDd4aOud5P8RAnJcAJ4n9Pt6JbYRlu2cmSTt91xM7IO8fACffUA7
rzoWMpWXPrNUxk+v/fDNeN8=
=Mxal
-----END PGP SIGNATURE-----
On Mon, Jan 17, 2005 at 02:47:32AM -0500, John Richard Moser wrote:
>
> Damn that sucks. I think stable releases need every patch audited
> before they get Linus' blessing, and unfortunately it seems we don't
> have the required 150+ people jumping up to volunteer. :(
>
> Yes I have unrealistic goals. Sane, but unrealistic. Perhaps
> collaboration with the major distributions to volunteer developers to do
> the auditing? We need SOMETHING; there's been too much line noise here
> about kernel security holes. Whether this is new or people are just
> noticing and overreacting now, it's still not good.
>
> Unfortunately, "Something" requires manpower. Manpower requires people
> who aren't busy doing other things, like improving preemptiveness,
> rewriting the VM system, enhancing the scheduler, or writing new
> drivers. And unfortunately, not only is everyone busy with all of that;
> but we NEED all of that too.
>
> Well, maybe you can't start up a group now, or implement audit policy;
> but perhaps the invitation needs to be there. I see there are no -audit
> or -security lists on vger; perhaps somebody should start a
> linux-kernel-audit@vger list just to get the ball rolling. If it grows
> big enough, then you can consider some policy about having the changes
> audited FIRST before releasing; for now that's just not feasible.
What exactly do you want to audit for?
If it's only for "ordinary" bugs, that's simply not feasible.
The amount of patches going into 2.6 is currently at about 3 MB every
week. You can hardly keep up with all of that - and even if you were
able to do so, some theoretically correct patch might break in practice
due to hardware bugs or bugs in some toolchain.
Regarding security audits:
They aren't a bad idea, and not bound to new patches - much legacy code
in the kernel has for sure more bugs than new code. The linus-kernel way
for such a project is not to scream "We need SOMETHING" - the
linux-kernel way is that you start with the work to get the ball rolling
(and if other people are interested to work in the same area, give them
some guidance).
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
El Mon, 17 Jan 2005 02:40:06 -0500 John Richard Moser <[email protected]> escribi?:
> -----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.
Most of the latest (ie: 2004) serious kernel holes (if not all) have been
found by the isec.pl guys (http://www.isec.pl/vulnerabilities.html), specially
Paul Starzetz. While they're not a "auditing project", the effect they're
having is the same.
(By the way, secunia reports that 48% of the vulnerabilities reported for
the linux kernel are not patched http://secunia.com/product/2719/ . I guess
they can't notice when bugs are fixed but I hope there's not any open hole
left)
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Diego Calleja wrote:
> El Mon, 17 Jan 2005 02:40:06 -0500 John Richard Moser <[email protected]> escribi?:
>
>
>>-----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.
>
>
>
> Most of the latest (ie: 2004) serious kernel holes (if not all) have been
> found by the isec.pl guys (http://www.isec.pl/vulnerabilities.html), specially
> Paul Starzetz. While they're not a "auditing project", the effect they're
> having is the same.
>
sweet.
>
> (By the way, secunia reports that 48% of the vulnerabilities reported for
> the linux kernel are not patched http://secunia.com/product/2719/ . I guess
> they can't notice when bugs are fixed but I hope there's not any open hole
> left)
There's probably open holes. Never assume there's not.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
- --
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
iD8DBQFB6/7shDd4aOud5P8RAuMXAJ4rv2TMVALf7OD1omtXd9QrY4Qz3wCeO1Y3
MIjR3sUE2D4xWbXrkeMbOWE=
=hmFl
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Adrian Bunk wrote:
> On Mon, Jan 17, 2005 at 02:47:32AM -0500, John Richard Moser wrote:
>
[...]
>
> What exactly do you want to audit for?
>
Security holes
> If it's only for "ordinary" bugs, that's simply not feasible.
> The amount of patches going into 2.6 is currently at about 3 MB every
> week. You can hardly keep up with all of that - and even if you were
> able to do so, some theoretically correct patch might break in practice
> due to hardware bugs or bugs in some toolchain.
>
Understood.
> Regarding security audits:
> They aren't a bad idea, and not bound to new patches - much legacy code
> in the kernel has for sure more bugs than new code. The linus-kernel way
> for such a project is not to scream "We need SOMETHING" - the
> linux-kernel way is that you start with the work to get the ball rolling
> (and if other people are interested to work in the same area, give them
> some guidance).
>
I'm nowhere near being able to actually do a security audit. I
understand what an audit is, I understand what causes vulnerabilities,
but I'd probably only be able to see the most obvious things (like
strcpy(a,"Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa") into a[4]).
If I had a few more years of experience, college out of the way, a good
job, and had some of my other projects moving along, maybe. . . .
> cu
> Adrian
>
- --
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
iD8DBQFB6/61hDd4aOud5P8RAiTiAJ4jUrPCHj3f+NT5RsgKUGUXO4PSGQCfXW3E
SWJkAfcoqcbW9hD2Ew33R18=
=hnty
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alan Cox wrote:
> 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 -
>
These are great, but I don't think such tools could cover all issues,
especially in the kernel (where hardware is a factor). Perhaps by
hammering a function with every input possible, but eh.
Humans create the tools, humans create the flaws. Thus, humans create
flaws in the tools. Humans of course aren't staticly flawed (as the
tools will be), so they or other humans can notice bugs they missed before.
> - 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.
>
\o/
> There are also people other than Linus who read every single changeset.
> I do for one.
>
"Read" and "Audit" are two different things. I can read a changeset and
see that a[10] got a 20 character string into it; I will NOT see that a
particular execution path 17 function calls long under one obscure but
possible and deliberately activatable condition causes memory corruption.
I thought the purpose of an audit was to sit down and give the code
several long, hard looks from different perspectives; though I've never
done one (I hope to in the future), so I wouldn't know would I?
Maybe I should stop talking before I make myself look stupider...
> Alan
- --
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
iD8DBQFB7AAjhDd4aOud5P8RAlQqAJ9eVwAClqkqMLETCyIFC6UeyKX0ogCfUUwN
2EWlPWnym7IHz4a/bVBQHmU=
=VpA2
-----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Alan Cox wrote:
[...]
> There are also people other than Linus who read every single changeset.
> I do for one.
>
Yes but (off the record) you people can't even keep hysterical raisins
out of fs/proc/base.c :)
[...]
- --
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
iD8DBQFB7BuFhDd4aOud5P8RAojIAJ48R+Ce7FzRLtnSEOye4bQreJPhRACcCemc
SjXU+ikTwmSEkiZV0m+7U7U=
=szjL
-----END PGP SIGNATURE-----