Is there a trojan in the Linux kernel?

We all suspect the existence of back doors in Windows, with its secret
and
proprietary source. But what about Linux? I don't quite believe the
hype
"open source, many eyes", for I myself never bother to examine a source
who
seems to work correctly, let alone a source as complex as the Linux
kernel.

So here is my conspiracy theory. Verify if you like. I have to publish
this
one because I feel uneasy with unexplainable behaviors.

Take a Linux source distribution, of any recent version. There is a
header
file include/linux/sched.h, which defines a structure called
task_struct.
This structure is of central importance, because it keeps kernel
informations about any running process. Take a look in the definition:
most
fields of the structure are mutually independent. Well, they should be.

Under any decent c compiler, the relative locations of independent
variables
must not affect the behavior of the compiled program. So why not try
with
task_struct: permute a few fields, or insert a line like that anywhere
in
the middle of the structure.

int unused;

Don't worry; the structure size won't overflow with a few more
integers.

Now recompile the kernel (with all the modules), install, and boot.
Keep
your rescue disk ready, because if you are as lucky as I am, a kernel
panick
is the most likely outcome.

So the question is: why should the positions of apparently independent
variables matter? It may simply be a stupid bug or a bad code design
somewhere, but in any case this can only occur when some code is
accessing a
variable without giving its name.

And this is typically the case when you want to hide what you want to
do
with your code. Suppose that you try to submit a code to the kernel
that can
change the uid of the process in order to gain root privileges. If you
write
to current->euid directly, people will immediately discover your trick,
by a
simple scan with grep. So you make a pointer, pointing to something
else.
Then add some value to the pointer, and you get the variable without
giving
its names!

Of course if the structure is permuted by a recompiler without
notifying you,
your pointer will point to something else, and that will very likely
crash
the kernel.

I would be glad to hear someone explain me the real reason behind this
kernel panick.

azuredu wrote:
> I would be glad to hear someone explain me the real reason behind this
> kernel panick.

If you really want to know the reason behind this behavior then ask it
on the Kernel mailing list instead than making up absurd conspiracy
theories. Unlike in Windows here you have the chance to actually talk
with the _real_ developers of the thing directly.
I'm sure they can give you a better answer than you might get on a
random Usenet NG.
There are many developers who work every day on the Kernel, from Kernel
developers to device drivers developers, and they are all independent
from each other, do you mean that them all want to spy on you?

Bye,
Luca

azuredu wrote:

[...]
> Under any decent c compiler, the relative locations of independent
> variables
> must not affect the behavior of the compiled program.

Wow! :)

[...]
> I would be glad to hear someone explain me the real reason behind this
> kernel panick.

if you look at generated assembler code you will see why it happens

=arvi=

azuredu wrote:
> We all suspect the existence of back doors in Windows, with its secret
> and
> proprietary source. But what about Linux? I don't quite believe the
> hype
> "open source, many eyes", for I myself never bother to examine a source
> who
> seems to work correctly, let alone a source as complex as the Linux
> kernel.
>
> So here is my conspiracy theory. Verify if you like. I have to publish
> this
> one because I feel uneasy with unexplainable behaviors.
>
> Take a Linux source distribution, of any recent version. There is a
> header
> file include/linux/sched.h, which defines a structure called
> task_struct.
> This structure is of central importance, because it keeps kernel
> informations about any running process. Take a look in the definition:
> most
> fields of the structure are mutually independent. Well, they should be.
>
> Under any decent c compiler, the relative locations of independent
> variables
> must not affect the behavior of the compiled program. So why not try
> with
> task_struct: permute a few fields, or insert a line like that anywhere
> in
> the middle of the structure.
>
> int unused;
>
> Don't worry; the structure size won't overflow with a few more
> integers.
>
> Now recompile the kernel (with all the modules), install, and boot.
> Keep
> your rescue disk ready, because if you are as lucky as I am, a kernel
> panick
> is the most likely outcome.
>
> So the question is: why should the positions of apparently independent
> variables matter? It may simply be a stupid bug or a bad code design
> somewhere, but in any case this can only occur when some code is
> accessing a
> variable without giving its name.
>
> And this is typically the case when you want to hide what you want to
> do
> with your code. Suppose that you try to submit a code to the kernel
> that can
> change the uid of the process in order to gain root privileges. If you
> write
> to current->euid directly, people will immediately discover your trick,
> by a
> simple scan with grep. So you make a pointer, pointing to something
> else.
> Then add some value to the pointer, and you get the variable without
> giving
> its names!
>
> Of course if the structure is permuted by a recompiler without
> notifying you,
> your pointer will point to something else, and that will very likely
> crash
> the kernel.
>
> I would be glad to hear someone explain me the real reason behind this
> kernel panick.
>
yes.......can be trojan.....
but i think u should think in another way,
because this is one benefit of open source,
u (or employ someone else does) can analyze the source code anytime
anywhere for any suspicious code in it.....that means...whenever u r
technical enough, u know if the code harms u......
if u use some proprietary.......hahaha.....how can u know if that black
box app harmful or not?.....maybe ur whole commercial biz data is being
captured somewhere else on the earth behind the scenes.....hahaha

Since there is a conspiracy, youwill just get lies. So use a debugger and
find out where the kernel is panicing.
Note that this post is a precise instance of the "many eyes" rule.
When did you last try an experiment like this with Windows?
"azuredu" <xiao@unice.fr> writes:

>We all suspect the existence of back doors in Windows, with its secret
>and
>proprietary source. But what about Linux? I don't quite believe the
>hype
>"open source, many eyes", for I myself never bother to examine a source
>who
>seems to work correctly, let alone a source as complex as the Linux
>kernel.

>So here is my conspiracy theory. Verify if you like. I have to publish
>this
>one because I feel uneasy with unexplainable behaviors.

>Take a Linux source distribution, of any recent version. There is a
>header
>file include/linux/sched.h, which defines a structure called
>task_struct.
>This structure is of central importance, because it keeps kernel
>informations about any running process. Take a look in the definition:
>most
>fields of the structure are mutually independent. Well, they should be.

>Under any decent c compiler, the relative locations of independent
>variables
>must not affect the behavior of the compiled program. So why not try
>with
>task_struct: permute a few fields, or insert a line like that anywhere
>in
>the middle of the structure.

>int unused;

>Don't worry; the structure size won't overflow with a few more
>integers.

>Now recompile the kernel (with all the modules), install, and boot.
>Keep
>your rescue disk ready, because if you are as lucky as I am, a kernel
>panick
>is the most likely outcome.

>So the question is: why should the positions of apparently independent
>variables matter? It may simply be a stupid bug or a bad code design
>somewhere, but in any case this can only occur when some code is
>accessing a
>variable without giving its name.

>And this is typically the case when you want to hide what you want to
>do
>with your code. Suppose that you try to submit a code to the kernel
>that can
>change the uid of the process in order to gain root privileges. If you
>write
>to current->euid directly, people will immediately discover your trick,
>by a
>simple scan with grep. So you make a pointer, pointing to something
>else.
>Then add some value to the pointer, and you get the variable without
>giving
>its names!

>Of course if the structure is permuted by a recompiler without
>notifying you,
>your pointer will point to something else, and that will very likely
>crash
>the kernel.

>I would be glad to hear someone explain me the real reason behind this
>kernel panick.

> When did you last try an experiment like this
> with Windows?

Sorry but I have never used Windows: DOS -> Linux in direct. Should be
a very rare example.

Well even if I did, I could never do the same experiment with Windows.
You can't recompile Windows! That's why I don't like it.

azuredu wrote:

> We all suspect the existence of back doors in Windows, with its secret
> and
> proprietary source. But what about Linux? I don't quite believe the
> hype
> "open source, many eyes", for I myself never bother to examine a source
> who
> seems to work correctly, let alone a source as complex as the Linux
> kernel.

[et cetera]

Your newsgroup reader doesn't
work:
Your postings sound like Captain
Kirk.

--
Peter Pearson
To get my email address, substitute:
nowhere -> spamcop, invalid -> net

On Fri, 06 May 2005 23:13:44 -0700, azuredu wrote:

[snip]
>
> I would be glad to hear someone explain me the real reason behind this
> kernel panick.


You did start with "make mrproper", right ?

> You did start with "make mrproper", right ?

No. And a simple "make clean" solves the problem. So this is just a
benign dependency bug. Thanks!