New RedHat Kernel Patch Illegal to Explain to U.S. Users

Russellkhan writes "The Register is running a story about a new RedHat kernel patch that cannot be explained to U.S. citizens or others in the U.S. because of DMCA restrictions. The illegal explanation is hosted at Thefreeworld.net, a site created specifically to deal with these DMCA issues."

Comments

Illegal if you live in the US, for NON-US ONLY!

[edgrale]

-- LEGALESE --

PLEASE READ FIRST.

Unfortunately the DMCA prevents this document being issued to US citizens.
This document is a copyrighted work. The authors choose to exercise their
first distribution rights to prohibit the distribution of this work in the
United States Of America, its dependancies, embassies and anywhere else
under US law.

Redistibuting this document in the USA may be a criminal offence under the
Digital Millenium Copyright Act with punishment including jail sentences.
Attempting to test these holes in the USA, even with the permission of the
system owner may be an offence. Discussing this document with a US citizen
may be an offence.

This document is made available for free without warranty or other right of
recourse implied or otherwise. No statement save one in writing by the owner
of the copyright changes this usage agreement. Any export download is at your
own risk and liability.

There is no other user agreement, should your local law make such an
agreement invalid you are prohibited from using this document, and may be
committing an offence by redistributing it.

NO WARRANTY

BECAUSE THE DOCUMENT IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE DOCUMENT, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE DOCUMENT "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE DOCUMENT IS WITH YOU. SHOULD THE
DOCUMENT PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE DOCUMENT AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE DOCUMENT (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE DOCUMENT TO OPERATE WITH ANY OTHER
DOCUMENTS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.

-- END LEGALESE --

Security Holes Fixed In Linux 2.4.19

None of the holes documented here are remote. All these problems were
uncovered by auditing and there are no current exploits available. In
the interest of openness and ensuring people are aware of the security
fixes they are documented.

- If the Stradis driver is loaded (hardware must be present) a
maths overflow allowed the user to scribble into kernel memory

- It was possible to feed the SE401 USB hardware driver signed
values and fool kernel checks. This requires the hardware is
present

- The usbvideo driver could be fooled due to a maths overflow corner
case. This requires drivers to be present

- The /proc/slabinfo file could exceed a buffer size and cause
corruption of the kernel. This is really beyond user control but
if it occurs then the user can trigger the corruption

- By setting the TF flag a carefully constructed binary could hang
the kernel dead

- By misusing the rlimit resource limits it was possible to avoid
acct data being written on your process exit

- The joystick driver had erroneous copies in obscure ioctl cases
that could be used to patch the kernel as any user. Hardware
must be present and the module loaded for this vulnerability
to occur

- Multiple errors in the vm86 handling allowed users to force an
"Oops" from the kernel and in some cases to corrupt kernel data.
An additional small fix is needed for 2.4.19 but not 2.4.19-ac
(see bottom)

- The rt_cache_proc file could be tricked into returning chunks of
kernel data.

- On a system with over 1Gb of RAM the loop driver could in some
cases fail and expose kernel data. This is not under user control.
On 2.4.19 the loop driver works fine with large memory systems.

- Multiple /proc files could be persuaded to dump kernel data
due to a sanity checking bug in the proc file handlers

- The XMM SSE registers were not always cleared for new processes
and could expose data from a different task. While it was not
possible to modify another tasks registers there is a small risk
because some cryptographic systems have XMM acceleration functions

We also fixed problems that required privileges to exploit. These affected
the IBM S/390 dasd driver, Openprom on Sparc systems, the Intermezzo file
system, the ewrk3 network driver, module loading, the microcode driver and
vm86. We document these in the interest of completeness.

Finally on a -ac based tree with PnPBIOS enabled a problem existed in some
quite common BIOS implementations that causes a crash when certain 32bit
BIOS calls are made. This allowed users to crash some systems by reading
files in /proc. These files are now root private. The base tree is not
affected as it lacks PnPBIOS support

Credits

The authors would like to thank Silvio Cesare, Stas Sergeev, Andi Kleen,
Alan Cox, Solar Designer, and many others for their work on making 2.4.19 a
more secure kernel.

-- Additional Required Patch --

diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.20pre1/arch/i386/kernel/traps.c linux.20pre1-ac1/arch/i386/kernel/traps.c
--- linux.20pre1/arch/i386/kernel/traps.c 2002-08-06 15:40:50.000000000 +0100
+++ linux.20pre1-ac1/arch/i386/kernel/traps.c 2002-08-06 15:42:19.000000000 +0100
@@ -305,8 +319,13 @@
static void inline do_trap(int trapnr, int signr, char *str, int vm86,
struct pt_regs * regs, long error_code, siginfo_t *info)
{
- if (vm86 && regs->eflags & VM_MASK)
- goto vm86_trap;
+ if (regs->eflags & VM_MASK) {
+ if (vm86)
+ goto vm86_trap;
+ else
+ goto trap_signal;
+ }
+
if (!(regs->xcs & 3))
goto kernel_trap;

@@ -514,10 +533,15 @@
{
unsigned int condition;
struct task_struct *tsk = current;
+ unsigned long eip = regs->eip;
siginfo_t info;

__asm__ __volatile__("movl %%db6,%0" : "=r" (condition));

+ /* If the user set TF, it's simplest to clear it right away. */
+ if ((eip >=PAGE_OFFSET) && (regs->eflags & TF_MASK))
+ goto clear_TF;
+ /* Mask out spurious debug traps due to lazy DR7 setting */
if (condition & (DR_TRAP0|DR_TRAP1|DR_TRAP2|DR_TRAP3)) {
if (!tsk->thread.debugreg[7])

Re:One day...

[flyneye]

uh,dopey,the DCMA came under the CLINTON administration. Perhaps if you actually had a handle on U.S. politics your humor wouldnt just signify your ignorance

This is absolutely silly

[Andy Dodd]

I don't recall the exact wording, but I'm positive the DMCA is intended to cover publishing vulnerabilities about *other people's software* - This is publishing information about THEIR OWN PRODUCT. Seems like someone is overreacting on this one to me.

HERE IT IS!!!! enjoy :-)

[Anonymous Coward]

Security Holes Fixed In Linux 2.4.19

None of the holes documented here are remote. All these problems were
uncovered by auditing and there are no current exploits available. In
the interest of openness and ensuring people are aware of the security
fixes they are documented.

- If the Stradis driver is loaded (hardware must be present) a
maths overflow allowed the user to scribble into kernel memory

- It was possible to feed the SE401 USB hardware driver signed
values and fool kernel checks. This requires the hardware is
present

- The usbvideo driver could be fooled due to a maths overflow corner
case. This requires drivers to be present

- The /proc/slabinfo file could exceed a buffer size and cause
corruption of the kernel. This is really beyond user control but
if it occurs then the user can trigger the corruption

- By setting the TF flag a carefully constructed binary could hang
the kernel dead

- By misusing the rlimit resource limits it was possible to avoid
acct data being written on your process exit

- The joystick driver had erroneous copies in obscure ioctl cases
that could be used to patch the kernel as any user. Hardware
must be present and the module loaded for this vulnerability
to occur

- Multiple errors in the vm86 handling allowed users to force an
"Oops" from the kernel and in some cases to corrupt kernel data.
An additional small fix is needed for 2.4.19 but not 2.4.19-ac
(see bottom)

- The rt_cache_proc file could be tricked into returning chunks of
kernel data.

- On a system with over 1Gb of RAM the loop driver could in some
cases fail and expose kernel data. This is not under user control.
On 2.4.19 the loop driver works fine with large memory systems.

- Multiple /proc files could be persuaded to dump kernel data
due to a sanity checking bug in the proc file handlers

- The XMM SSE registers were not always cleared for new processes
and could expose data from a different task. While it was not
possible to modify another tasks registers there is a small risk
because some cryptographic systems have XMM acceleration functions

We also fixed problems that required privileges to exploit. These affected
the IBM S/390 dasd driver, Openprom on Sparc systems, the Intermezzo file
system, the ewrk3 network driver, module loading, the microcode driver and
vm86. We document these in the interest of completeness.

Finally on a -ac based tree with PnPBIOS enabled a problem existed in some
quite common BIOS implementations that causes a crash when certain 32bit
BIOS calls are made. This allowed users to crash some systems by reading
files in /proc. These files are now root private. The base tree is not
affected as it lacks PnPBIOS support

Credits

The authors would like to thank Silvio Cesare, Stas Sergeev, Andi Kleen,
Alan Cox, Solar Designer, and many others for their work on making 2.4.19 a
more secure kernel.

-- Additional Required Patch --

diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.20pre1/arch/i386/kernel/traps.c linux.20pre1-ac1/arch/i386/kernel/traps.c
--- linux.20pre1/arch/i386/kernel/traps.c 2002-08-06 15:40:50.000000000 +0100
+++ linux.20pre1-ac1/arch/i386/kernel/traps.c 2002-08-06 15:42:19.000000000 +0100
@@ -305,8 +319,13 @@
static void inline do_trap(int trapnr, int signr, char *str, int vm86,
struct pt_regs * regs, long error_code, siginfo_t *info)
{
- if (vm86 && regs->eflags & VM_MASK)
- goto vm86_trap;
+ if (regs->eflags & VM_MASK) {
+ if (vm86)
+ goto vm86_trap;
+ else
+ goto trap_signal;
+ }
+
if (!(regs->xcs & 3))
goto kernel_trap;

@@ -514,10 +533,15 @@
{
unsigned int condition;
struct task_struct *tsk = current;
+ unsigned long eip = regs->eip;
siginfo_t info;

__asm__ __volatile__("movl %%db6,%0" : "=r" (condition));

+ /* If the user set TF, it's simplest to clear it right away. */
+ if ((eip >=PAGE_OFFSET) && (regs->eflags & TF_MASK))
+ goto clear_TF;
+
/* Mask out spurious debug traps due to lazy DR7 setting */
if (condition & (DR_TRAP0|DR_TRAP1|DR_TRAP2|DR_TRAP3)) {
if (!tsk->thread.debugreg[7])

Alan Cox works for red-hat.

[leuk_he]

Alan Cox works for red-hat.

Re:An Idea

[Anonymous Coward]

nah they would have to start it first :)

Re:Sound familiar?

[Latent IT]

What "international law" requires any country to make a fancy little "declairation of war" when it defends itself (always allowed under the UN Charter) or when it attacks another country?

Your statement is FALSE and you have provided NO SUPPORT for it.

I agree completely. He argues like my wife - just keep saying the same thing over and over again, a little differently.

Dear, is that you?

(--- Please Read!

[Tom7]

I posted late, but I hope my comment won't get lost in all of the noise...