C's trikery semantic opens up backdoor in new Linux kernel

C's trikery semantic opens up backdoor in new Linux kernel

[Adrian Hoe]

Hi,

Thought this would be an interesting article to share. Someone should 
convince Mr. Torvalds to switch to Ada. :)

http://www.theregister.co.uk/content/55/33855.html
-- 
Adrian Hoe
m a i l b o x AT a d r i a n h o e . c o m

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Stephane Richard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

For some reason, I can't open that link you posted here..

-- 
"To err is human.  To really screw up, you need C++!"

St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com


"Adrian Hoe" <adrianhoe@nowhere.com> wrote in message
news:3FB1A63C.9080200@nowhere.com...
> Hi,
>
> Thought this would be an interesting article to share. Someone should
> convince Mr. Torvalds to switch to Ada. :)
>
> http://www.theregister.co.uk/content/55/33855.html
> -- 
> Adrian Hoe
> m a i l b o x AT a d r i a n h o e . c o m
>

Re: C's trikery semantic opens up backdoor in new Linux kernel

[J Cusick]

On Wed, 12 Nov 2003 04:26:44 +0000, Stephane Richard wrote:

> For some reason, I can't open that link you posted here..

The Register site seems to be down at the moment... The link is good.

The article discusses the fact that someone tried to slide in a C line 
(actually 2 lines) that trashed the tcp stack allowing a negative offset
in a fragment to crash the stack (if I remember somewhat accurately)
Luckily it was caught before it was rolled in to the official distro.

The thoughts that goes through one's mind are interesting while reading
this... Bill G. has lots of money, I wonder how much this would have
dented his pocketbook? :-)

John C. 

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Vinzent 'Gadget' Hoefler]

J Cusick wrote:

>On Wed, 12 Nov 2003 04:26:44 +0000, Stephane Richard wrote:
>
>> For some reason, I can't open that link you posted here..
>
>The Register site seems to be down at the moment... The link is good.
>
>The article discusses the fact that someone tried to slide in a C line 
>(actually 2 lines) that trashed the tcp stack allowing a negative offset

No. It is worse than that.

The interesting line in question is this one:

|if ((options == (__WCLONE|__WALL)) && (current->uid = 0))

First this looks like a sanity check. But look closer. This single
line serves one single purpose: to give you root-privileges when you
just pass the right flags. Note the "current->uid = 0" instead of
"current->uid == 0". Who the hell had the fucking bad idea that
assignments could return values?

Let's stretch the example and imagine, it was just a simple typo of a
tired programmer who wrote the PIN-code checking routine for an ATM
and it slipped through the review...


Vinzent.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Duncan Sands]

> The interesting line in question is this one:
> |if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
>
> First this looks like a sanity check. But look closer. This single
> line serves one single purpose: to give you root-privileges when you
> just pass the right flags. Note the "current->uid = 0" instead of
> "current->uid == 0". Who the hell had the fucking bad idea that
> assignments could return values?

IMHO the real problem is that uid is not an opaque type and can
be changed with a simple assignment.  Much better if that required
a function call.

All the best,

Duncan.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Adrian Hoe]

J Cusick wrote:

> On Wed, 12 Nov 2003 04:26:44 +0000, Stephane Richard wrote:
> 
> 
>>For some reason, I can't open that link you posted here..
>>
> 
> The Register site seems to be down at the moment... The link is good.
> 
> The article discusses the fact that someone tried to slide in a C line 
> (actually 2 lines) that trashed the tcp stack allowing a negative offset
> in a fragment to crash the stack (if I remember somewhat accurately)
> Luckily it was caught before it was rolled in to the official distro.



Yeah, = and == make a lot of difference. It supposed to be:


someone == root

but it turned up to be

some = root

That's catastrophic!

 
> The thoughts that goes through one's mind are interesting while reading
> this... Bill G. has lots of money, I wonder how much this would have
> dented his pocketbook? :-)


I think he would not care about it. It is not his money but those poor 
M$ users! Bill still can make a great fortune after all!
-- 
Adrian Hoe
m a i l b o x AT a d r i a n h o e . c o m

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Adrian Hoe]

Stephane Richard wrote:

> For some reason, I can't open that link you posted here..



It is fine on my end here. The link or the server might be down. Try 
again later.
-- 
Adrian Hoe
m a i l b o x AT a d r i a n h o e . c o m

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Vinzent 'Gadget' Hoefler]

Duncan Sands wrote:

>> The interesting line in question is this one:
>> |if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
>>
>> First this looks like a sanity check. But look closer. This single
>> line serves one single purpose: to give you root-privileges when you
>> just pass the right flags. Note the "current->uid = 0" instead of
>> "current->uid == 0". Who the hell had the fucking bad idea that
>> assignments could return values?
>
>IMHO the real problem is that

the syntax of C allows such things. Simple as that, it doesn't matter
if you even can set strict coding standards to make such things hardly
possible.

>uid is not an opaque type and can
>be changed with a simple assignment.  Much better if that required
>a function call.

You can almost always find a workaround. The problem is to use it
everytime and force people to use it.

For instance considering the simple rule that in a comparison with a
constant value you should always state the constant first:

|if ((__WCLONE|__WALL) == options) && (0 = current->uid))

wouldn't compile, either.


Vinzent.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Preben Randhol]

On 2003-11-12, Adrian Hoe <adrianhoe@nowhere.com> wrote:
> Yeah, = and == make a lot of difference. It supposed to be:
>
>
> someone == root
>
> but it turned up to be
>
> some = root
>
> That's catastrophic!

And I thought ==, +=, -= should be so much more readable as 5 languages
use them ;-)

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Duncan Sands]

> >IMHO the real problem is that
>
> the syntax of C allows such things. Simple as that, it doesn't matter
> if you even can set strict coding standards to make such things hardly
> possible.
>
> >uid is not an opaque type and can
> >be changed with a simple assignment.  Much better if that required
> >a function call.
>
> You can almost always find a workaround. The problem is to use it
> everytime and force people to use it.

I was under the impression that (using preprocessor trickery) it was possible
to get the equivalent of an Ada private type in C.  Then everyone is forced
to use function calls to get/set the value, unless they do type casts etc.
In all cases, abuse would stand out more than it does now.

> For instance considering the simple rule that in a comparison with a
>
> constant value you should always state the constant first:
> |if ((__WCLONE|__WALL) == options) && (0 = current->uid))
>
> wouldn't compile, either.

No, but do you really think such a style could be enforced in the linux
kernel community?  Think of "herding cats".

Duncan.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Vinzent 'Gadget' Hoefler]

Duncan Sands wrote:

>I was under the impression that (using preprocessor trickery) it was possible
>to get the equivalent of an Ada private type in C.

Uhuh. Hmm. Quite possible. I've seen a lot of things with the damn
preprocessor... ;)

>  Then everyone is forced
>to use function calls to get/set the value, unless they do type casts etc.
>In all cases, abuse would stand out more than it does now.

Yes.

>> For instance considering the simple rule that in a comparison with a
>>
>> constant value you should always state the constant first:
>> |if ((__WCLONE|__WALL) == options) && (0 = current->uid))
>>
>> wouldn't compile, either.
>
>No, but do you really think such a style could be enforced in the linux
>kernel community?

No. And you? Do you really think that the linux kernel community would
like the idea of using a *function* to get/set a plain simple integer
variable? I already hear them scream: "It would be too inefficient.
Especially in a *kernel*!" ;-)

>Think of "herding cats".

I did. :)


Vinzent.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[tmoran]

> |if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
It used to be that the "Obfuscated C" contest was just about fame.
Now it's also about fortune.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Warren W. Gay VE3WWG]

Vinzent 'Gadget' Hoefler wrote:
> J Cusick wrote:
>>On Wed, 12 Nov 2003 04:26:44 +0000, Stephane Richard wrote:
>>>For some reason, I can't open that link you posted here..
>>
>>The Register site seems to be down at the moment... The link is good.
>>
>>The article discusses the fact that someone tried to slide in a C line 
>>(actually 2 lines) that trashed the tcp stack allowing a negative offset
> 
> No. It is worse than that.
> 
> The interesting line in question is this one:
> 
> |if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
> 
> First this looks like a sanity check. But look closer. This single
> line serves one single purpose: to give you root-privileges when you
> just pass the right flags. Note the "current->uid = 0" instead of
> "current->uid == 0". Who the hell had the ******* bad idea that
> assignments could return values?

It was a matter of time before this happened. But to be fair to
C, this is a problem with any large body of code. How carefully
is every source line submission scrutinized?

As the quantity of code increases, the likelyhood of some other
subtle change like this being introduced increases. Linux as
Open Source enjoys the advantage of many eyes, which helps. But
it also enjoys the slight disadvantage of "many submissions" as
well ;-)

I do accept that Ada95 would make this more difficult to do,
but this seems to be all academic talk for the moment ;-)

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Wes Groleau]

> Yeah, = and == make a lot of difference. It supposed to be:
> 
> someone == root
> 
> but it turned up to be
> 
> some = root

Correction: it was intended to LOOK LIKE

someone == root

but the

some = root

was intentional, and the CM mechanism was cheated
to get it in without tracing it to who did it.


-- 
Wes Groleau
   "Grant me the serenity to accept those I cannot change;
    the courage to change the one I can;
    and the wisdom to know it's me."
                                -- unknown

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Chad R. Meiners]

"Preben Randhol" <randhol+valid_for_reply_from_news@pvv.org> wrote in
message
news:slrnbr4a2k.6f3.randhol+valid_for_reply_from_news@kiuk0156.chembio.ntnu.no...
>
> And I thought ==, +=, -= should be so much more readable as 5 languages
> use them ;-)

A little off topic but if you have a  += type operator why doesn't x == y
mean x := (x = y) (the second part isn't c of course ;)

A little inconsistent if you ask me ;-)

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Craig Carey]

On Wed, 12 Nov 2003 15:09:52 +0100, Vinzent 'Gadget' Hoefler wrote:
...
>Duncan Sands wrote:
...
>>> constant value you should always state the constant first:
>>> |if ((__WCLONE|__WALL) == options) && (0 = current->uid))
>>>
>>> wouldn't compile, either.

...
>No. And you? Do you really think that the linux kernel community would
>like the idea of using a *function* to get/set a plain simple integer
>variable? I already hear them scream: "It would be too inefficient.
>Especially in a *kernel*!" ;-)

Ada 95 could be enhanced so that specified record fields could be
read-only. Some one could perhaps produce data showing that it is needed
or else it may not appear.

De-referenced pointers can identify read-only data
  "type Ptr is access constant X;".
Then Ada 95 lacks a limited pointer type, and also a pointer that can
be assigned but which lacks a "=" equality operator.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Adrian Hoe]

Wes Groleau wrote:

> 
>> Yeah, = and == make a lot of difference. It supposed to be:
>>
>> someone == root
>>
>> but it turned up to be
>>
>> some = root
> 
> 
> Correction: it was intended to LOOK LIKE
> 
> someone == root
> 
> but the
> 
> some = root
> 
> was intentional, and the CM mechanism was cheated
> to get it in without tracing it to who did it.
> 
> 


According to my understanding of the article, it was intended like this:

if someone == root

but the statement was deliberately/mistakenly written like this:

if some = root



Consider this:

int main()
{

    int root = 1;
    int someone;

    someone=root;

    if (someone==root) {
       printf ("Some is root!\n");
    }

    if (someone=root) {     /* this cannot happen in Ada */
       printf ("Some has become root!\n");
    }
}



-- 
Adrian Hoe
m a i l b o x AT a d r i a n h o e . c o m

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Freejack]

On Thu, 13 Nov 2003 16:04:02 -0500, Craig Carey wrote:

> On Wed, 12 Nov 2003 15:09:52 +0100, Vinzent 'Gadget' Hoefler wrote: ...
> 
> Ada 95 could be enhanced so that specified record fields could be
> read-only. Some one could perhaps produce data showing that it is needed
> or else it may not appear.
> 
> De-referenced pointers can identify read-only data
>   "type Ptr is access constant X;".
> Then Ada 95 lacks a limited pointer type, and also a pointer that can be
> assigned but which lacks a "=" equality operator.
 
Perhaps the introduction of a "Concatenated Type" would be helpful
here.

i.e. type Ptr is tagged access X; or some such.

The idea is thus...

	x = 2 + 3 squared
	  = 5 squared
	  = 5 * 5
	  = 25

All the functions are equivalent. Hence one could create function
pointers that are extended to point to all the functions that are
equivalent. Then one could optimize each function as long as the 
optimization does not take it out of the equality bounds.

I'm dont know if there is a way to compare Instantiations of "function
Get(X)'Class" to test for equality.

Anyways, using this method, not only would writing the to access value be
prevented, reading it outside the methods would also be unneeded.

Arg. Perhaps a little more indepth explanations is necessary.

http://www.latrobe.edu.au/philosophy/phimvt/joy/j02maf.html
http://www.latrobe.edu.au/philosophy/phimvt/joy/j04alg.html

Please ignore the atrocious syntax of that language. I find the concepts
though to be very interesting. I would not care to go whole hog with it,
but some of it might be useful.

Freejack

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Erlo Haugen]

On Fri, 14 Nov 2003 10:04:02 +1300
Craig Carey <research@ijs.co.nz> wrote:

> On Wed, 12 Nov 2003 15:09:52 +0100, Vinzent 'Gadget' Hoefler wrote:
> ...
> >Duncan Sands wrote:
> ...
> >>> constant value you should always state the constant first:
> >>> |if ((__WCLONE|__WALL) == options) && (0 = current->uid))
> >>>
> >>> wouldn't compile, either.
> 
> ...
> >No. And you? Do you really think that the linux kernel community would
> >like the idea of using a *function* to get/set a plain simple integer
> >variable? I already hear them scream: "It would be too inefficient.
> >Especially in a *kernel*!" ;-)
> 
> Ada 95 could be enhanced so that specified record fields could be
> read-only. Some one could perhaps produce data showing that it is needed
> or else it may not appear.
> 
> De-referenced pointers can identify read-only data
>   "type Ptr is access constant X;".
> Then Ada 95 lacks a limited pointer type, and also a pointer that can
> be assigned but which lacks a "=" equality operator.
> 
> 
> 
> 

Isn't this a matter of optmization? If all the function does is assigning a
value, then the compiler could convert it an inline assignment:

My_Variable : something;
function Get_A return something is
begin
  return My_Variable;
end Get_A;



then (possibly in another package)

.
.
.
This_Variable := Other_Package.Get_A;
.
.

could be optimized (in the object code)to

.
.
.
This_Variable := Other_Package.My_Variable;
.
.
.



Just a thought, I don't know much about compiler construction, but it seems to
me to be a way to go.

-- 
Erlo
Remove the underscores
Sorry, I don't have time for this. I've got bugs to write.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Vinzent 'Gadget' Hoefler]

Erlo Haugen wrote:

>On Fri, 14 Nov 2003 10:04:02 +1300
>Craig Carey <research@ijs.co.nz> wrote:
>
>> On Wed, 12 Nov 2003 15:09:52 +0100, Vinzent 'Gadget' Hoefler wrote:
>> ...
>> >No. And you? Do you really think that the linux kernel community would
>> >like the idea of using a *function* to get/set a plain simple integer
>> >variable? I already hear them scream: "It would be too inefficient.
>> >Especially in a *kernel*!" ;-)
>> 
>> Ada 95 could be enhanced so that specified record fields could be
>> read-only.

BTW, this is a neat idea. OTOH, for this approach to be practical
someone *must* have write access.

>Isn't this a matter of optmization?

Precisely. AFAICS.


Vinzent.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Dmitry A. Kazakov]

On Fri, 14 Nov 2003 10:44:47 +0100, Vinzent 'Gadget' Hoefler
<ada.rocks@jlfencey.com> wrote:

>Erlo Haugen wrote:
>
>>On Fri, 14 Nov 2003 10:04:02 +1300
>>Craig Carey <research@ijs.co.nz> wrote:
>>
>>> On Wed, 12 Nov 2003 15:09:52 +0100, Vinzent 'Gadget' Hoefler wrote:
>>> ...
>>> >No. And you? Do you really think that the linux kernel community would
>>> >like the idea of using a *function* to get/set a plain simple integer
>>> >variable? I already hear them scream: "It would be too inefficient.
>>> >Especially in a *kernel*!" ;-)
>>> 
>>> Ada 95 could be enhanced so that specified record fields could be
>>> read-only.
>
>BTW, this is a neat idea. OTOH, for this approach to be practical
>someone *must* have write access.

1. Not always. We already have constant "record" fields in Ada. They
are called discriminants.

2. Constructor

--
Regards,
Dmitry Kazakov
http://www.dmitry-kazakov.de

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Dmytry Lavrov]

> > > + if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
> > > + retval = -EINVAL;

Hahaha......(falling ,and still laughing!)

So cool!

anyway, 0==something looks like complete idiotism for me,perhaps for
that guy too ;-))).Someone with Pascal background,or hacker or it's
simply typo,or all together ;-))))

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Georg Bauhaus]

Vinzent 'Gadget' Hoefler <ada.rocks@jlfencey.com> wrote:
: No. And you? Do you really think that the linux kernel community would
: like the idea of using a *function* to get/set a plain simple integer
: variable? I already hear them scream: "It would be too inefficient.
: Especially in a *kernel*!" ;-)

Though all you have to explain is pragma Inline and -gnatn or
-gnatN and show them the disassembly...


:>Think of "herding cats".
: 
: I did. :)

If you tell them that pragma Inline is standard and supported
in GCC, that should be impressive?


-- Georg

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Duncan Sands]

> Though all you have to explain is pragma Inline and -gnatn or
> -gnatN and show them the disassembly...
>
> :>Think of "herding cats".
> :
> : I did. :)
>
> If you tell them that pragma Inline is standard and supported
> in GCC, that should be impressive?

They will laugh at you.

Duncan.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Vinzent 'Gadget' Hoefler]

Georg Bauhaus wrote:

>Vinzent 'Gadget' Hoefler <ada.rocks@jlfencey.com> wrote:
>: No. And you? Do you really think that the linux kernel community would
>: like the idea of using a *function* to get/set a plain simple integer
>: variable? I already hear them scream: "It would be too inefficient.
>: Especially in a *kernel*!" ;-)
>
>Though all you have to explain is pragma Inline and -gnatn or
>-gnatN and show them the disassembly...

Yes.

>If you tell them that pragma Inline is standard and supported
>in GCC, that should be impressive?

Of course. But think about it: Isn't it a funny thing that you can do
a thing efficient enough in Ada just to prevent a problem in C, which
OTOH you even wouldn't have at all if you'd use Ada in the first
place?

What's the definition for this sort of stuff called?


Vinzent.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Georg Bauhaus]

Vinzent 'Gadget' Hoefler <ada.rocks@jlfencey.com> wrote:
: Of course. But think about it: Isn't it a funny thing that you can do
: a thing efficient enough in Ada just to prevent a problem in C, which
: OTOH you even wouldn't have at all if you'd use Ada in the first
: place?
 
: What's the definition for this sort of stuff called?

Windows 3.1?  Will they still laugh at me now, Duncan? :-)


-- Georg

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Robert I. Eachus]

Craig Carey wrote:

> Ada 95 could be enhanced so that specified record fields could be
> read-only. Some one could perhaps produce data showing that it is needed
> or else it may not appear.

No problem in this case, and I have used the particular trick.  If a 
record type has discriminants and contains a limited component, then the 
only way to change the discriminant is with an aggregate assignment, and 
you can't do that for a limited type.  Note that the type can be 
non-limited in the (private part and) body of the package that declares 
it, so you can change the discriminants if necessary.

You can also use Unchecked_Conversion, or a call to a C routine with the 
object passed by reference.  Both of these should set off warning flags 
if you are really worried about covert channels.  Where I have used the 
"trick" however, the goal was to avoid unintentional changes to some 
values--the discriminants--while allowing changes to others.

-- 
                                           Robert I. Eachus

100% Ada, no bugs--the only way to create software.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Duncan Sands]

On Friday 14 November 2003 16:08, Georg Bauhaus wrote:
> Vinzent 'Gadget' Hoefler <ada.rocks@jlfencey.com> wrote:
> : Of course. But think about it: Isn't it a funny thing that you can do
> : a thing efficient enough in Ada just to prevent a problem in C, which
> : OTOH you even wouldn't have at all if you'd use Ada in the first
> : place?
> :
> : What's the definition for this sort of stuff called?
>
> Windows 3.1?  Will they still laugh at me now, Duncan? :-)

Hey - I liked windows 3.1!  After all, it made my OS/2 system look so spiffy. :)

By the way, here is an extract from the linux kernel documentation:


-------------------

2) #ifdefs are ugly

Code cluttered with ifdefs is difficult to read and maintain.  Don't do
it.  Instead, put your ifdefs in a header, and conditionally define
'static inline' functions, or macros, which are used in the code.
Let the compiler optimize away the "no-op" case.

Simple example, of poor code:

	dev = init_etherdev (NULL, 0);
	if (!dev)
		return -ENODEV;
	#ifdef CONFIG_NET_FUNKINESS
	init_funky_net(dev);
	#endif

Cleaned-up example:

(in header)
	#ifndef CONFIG_NET_FUNKINESS
	static inline void init_funky_net (struct net_device *d) {}
	#endif

(in the code itself)
	dev = init_etherdev (NULL, 0);
	if (!dev)
		return -ENODEV;
	init_funky_net(dev);



3) 'static inline' is better than a macro

Static inline functions are greatly preferred over macros.
They provide type safety, have no length limitations, no formatting
limitations, and under gcc they are as cheap as macros.

Macros should only be used for cases where a static inline is clearly
suboptimal [there a few, isolated cases of this in fast paths],
or where it is impossible to use a static inline function [such as
string-izing].

'static inline' is preferred over 'static __inline__', 'extern inline',
and 'extern __inline__'.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Robert I. Eachus]

Vinzent 'Gadget' Hoefler wrote:

>>>For instance considering the simple rule that in a comparison with a
>>>
>>>constant value you should always state the constant first:
>>>|if ((__WCLONE|__WALL) == options) && (0 = current->uid))
>>>
>>>wouldn't compile, either.
>>
>>No, but do you really think such a style could be enforced in the linux
>>kernel community?

> No. And you? Do you really think that the linux kernel community would
> like the idea of using a *function* to get/set a plain simple integer
> variable? I already hear them scream: "It would be too inefficient.
> Especially in a *kernel*!" ;-)

Bad example here.  GCC will print a warning message about assignment in 
condition clauses unless the assignment is enclosed in parentheses. So:

if (options == (__WCLONE|__WALL) && current->uid = 0)

would generate a compiler warning message about the assignment to 
current -> uid.  The Linux kernel coding standards make "redundant" 
parentheses in conditions illegal for exactly that reason, and one of 
the things that made it clear that this was an intentional attempt to 
get root was the "extra" parentheses.

-- 
                                           Robert I. Eachus

100% Ada, no bugs--the only way to create software.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Vinzent 'Gadget' Hoefler]

Robert I. Eachus wrote:

>if (options == (__WCLONE|__WALL) && current->uid = 0)
>
>would generate a compiler warning message about the assignment to 
>current -> uid.  The Linux kernel coding standards make "redundant" 
>parentheses in conditions illegal for exactly that reason,

So you're saying that a style to use parentheses where it is not
*absolutely* clear which is meant is a bad style? Yes, I am talking
about operator precedence, this is especially bad in C where
programmer and compiler might have different opinions about a
particular construct and still it compiles.

>and one of 
>the things that made it clear that this was an intentional attempt to 
>get root was the "extra" parentheses.

The circumstances tell us that this was intentional, yes.

I'd use constants on the left side, but suppose I would not do that,
then I would more tend to write:

|if ((options == (__WCLONE|__WALL)) && (current->uid == 0))

without any bad ideas in mind.

Hmm. Now the typo, a job on a banking account system and, because I
wrote the parentheses, which in turn prove I was intentionally doing
that, I'm going to jail.


Vinzent.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Georg Bauhaus]

Duncan Sands <baldrick@free.fr> wrote:
: On Friday 14 November 2003 16:08, Georg Bauhaus wrote:
:> Vinzent 'Gadget' Hoefler <ada.rocks@jlfencey.com> wrote:
:> : Of course. But think about it: Isn't it a funny thing that you can do
:> : a thing efficient enough in Ada just to prevent a problem in C, which
:> : OTOH you even wouldn't have at all if you'd use Ada in the first
:> : place?
:> :
: 
: By the way, here is an extract from the linux kernel documentation:
: 
: 3) 'static inline' is better than a macro
: 
: 'static inline' is preferred over 'static __inline__', 'extern inline',
: and 'extern __inline__'.

So there is no inlining problem in C.
Is there still resitance to using a function then?
If so, is it an effect of a "C mindset"?


-- Georg

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Adrian Hoe]

Dmytry Lavrov wrote:

>>>>+ if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
>>>>+ retval = -EINVAL;
>>>>
> 
> Hahaha......(falling ,and still laughing!)
> 
> So cool!
> 
> anyway, 0==something looks like complete idiotism for me,perhaps for
> that guy too ;-))).Someone with Pascal background,or hacker or it's
> simply typo,or all together ;-))))
> 


LOL... :D
-- 
Adrian Hoe
m a i l b o x AT a d r i a n h o e . c o m

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Adrian Hoe]

On second thought, this is a great example for my Ada Seminar. I shall 
include it into the slides.




Dmytry Lavrov wrote:

>>>>+ if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
>>>>+ retval = -EINVAL;
>>>>
> 
> Hahaha......(falling ,and still laughing!)
> 
> So cool!
> 
> anyway, 0==something looks like complete idiotism for me,perhaps for
> that guy too ;-))).Someone with Pascal background,or hacker or it's
> simply typo,or all together ;-))))
> 


-- 
Adrian Hoe
m a i l b o x AT a d r i a n h o e . c o m

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Wes Groleau]

Adrian Hoe wrote:
> According to my understanding of the article, it was intended like this:
> 
> if someone == root
> 
> but the statement was deliberately/mistakenly written like this:
> 
> if some = root

Let me put it another way.

The cracker meant it to be an assignment, and
he/she also intended for it to not be noticed.

-- 
Wes Groleau
When all you have is a perl, everything looks like a string.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Dmytry Lavrov]

Adrian Hoe <adrianhoe@nowhere.com> wrote in message news:<3FB5B35E.7060900@nowhere.com>...
> On second thought, this is a great example for my Ada Seminar. I shall 
> include it into the slides.

On my second:
i have readed somewhere on that web links,that it's "surely very smart
hacker":
"he also added extra () to avoid warnings..." ;-)

I can write in pascal/ada:

if (options=__WCLONE or __WALL)and(current.uid=0) then something

,that () are really needed because "and" have bigger priority than "="
so it's why i said about pascal background:it's very possible to be
typo,everyone with pascal background working in C many times maked
such mistakes,avoiding all warnings ;-)!
And i think after spending days/weeks, foget that nightmare is quite
hard.(anyway,somehow i newer maked that bug yet,only because i know
that mistake)

Or it's hacker with pascal background ,or he know someone with pascal
background and that mistakes,in any case somehow he know that common
pascal-->c typo and was able to insert it. Or it's really typo that
someone wasn't removed,just because it's so cool,saying for
himself:it's test if they check code...it's only test... ;-) .
(Raskolnikov,blin ;-)

They also truing to put that it's someone hacked CVS and added it into
code.
IMO quite inprobable.;-)if so,that hacker was able to put it into old
code,avoiding problems with reviews,and it's also possible to hack all
main CVS'es avoiding problems with updates, if you can hack one
CVS,you can hack all.

I really worry now,almost all commercial code probably contain such
cool things...including safety critical c code in airplanes...nuclair
plants...almost everyone,not only with pascal background, can make
that typo,find it,and then not remove because it's too cool...

....just for tesst,jussst for tessst,my beauty...ssss....
...and then it's too late to show it...

....good idea: that mistake as ring in "Lord of the Ring"....


Regards,

Dmytry Lavrov.
p.s.
if it's hacker,probably there's should be other bugs left to use that
trojan, some bugs(buffer overflow) allows remote user to execute his
code,but non-root.Else that trojan don't make impact on,for
example,me. It's only bad for website hosting servers,if you have
account,and for other multiuser systems.Why he need to hack multi-user
systems...don't know why he may need that.

So if it's hacker,at least 1/2 or more probablity that one other
trojan left unnoticed( not in kernel,in netscape or other internet
prog...like Morriss'days bug ).

More nice typos with *....

> 
> Dmytry Lavrov wrote:
> 
> >>>>+ if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
> >>>>+ retval = -EINVAL;
> >>>>
> > 
> > Hahaha......(falling ,and still laughing!)
> > 
> > So cool!
> > 
> > anyway, 0==something looks like complete idiotism for me,perhaps for
> > that guy too ;-))).Someone with Pascal background,or hacker or it's
> > simply typo,or all together ;-))))
> >

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Dmytry Lavrov]

Heh,that hackers added trojans into C language!
It's many hackers,and they working together... :)
(banning non-c-based-languages,etc)

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Warren W. Gay VE3WWG]

Dmytry Lavrov wrote:
> Adrian Hoe <adrianhoe@nowhere.com> wrote in message news:<3FB5B35E.7060900@nowhere.com>...
> 
>>On second thought, this is a great example for my Ada Seminar. I shall 
>>include it into the slides.
> 
> 
> On my second:
> i have readed somewhere on that web links,that it's "surely very smart
> hacker":
> "he also added extra () to avoid warnings..." ;-)

He probably was warned by the compiler first, and _then_
added () as an afterthought, before submitting the
patches.  It was GCC that was smart.  ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Dave Thompson]

On Wed, 12 Nov 2003 14:38:06 +0100, Duncan Sands <baldrick@free.fr>
wrote:

> > >IMHO the real problem is that
<snip>
> > >uid is not an opaque type and can
> > >be changed with a simple assignment.  Much better if that required
> > >a function call.
> >
> > You can almost always find a workaround. The problem is to use it
> > everytime and force people to use it.
> 
> I was under the impression that (using preprocessor trickery) it was possible
> to get the equivalent of an Ada private type in C.  Then everyone is forced
> to use function calls to get/set the value, unless they do type casts etc.
> In all cases, abuse would stand out more than it does now.
> 
There's nothing you can do with the C preprocessor that can't be done
directly in source -- because the preprocessor is a source-to-source
transform (actually source to lexed-source, but that's equivalent in
capability). The only compiler-enforced opaque types in C are
incomplete aka "forward" struct and union tags. And, probably sadly,
there are enough places in most large C programs where casts are
legitimately used that a few more don't stand out that much.

You can make it harder to find/see things, like typedefs, by burying
them in #include files, perhaps several layers deep in confusing
#if's, but they're there somewhere and someone who goes to the effort
can find and use them. You can use BIG_UGLY_NAMES that attract
scrutiny if actually written in source -- like Ada's UNCHECKED_* but
more so because you can't substitute lowercase.

For assignment, you can with a little extra work create and expose
only a const pointer to data that is actually variable; this then can
be assigned to only in code that has the "variable view" OR by casting
the pointer to non-const, which is at least mildly inconvenient.

- David.Thompson1 at worldnet.att.net

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Martin Krischik]

Dave Thompson wrote:

> There's nothing you can do with the C preprocessor that can't be done
> directly in source -- because the preprocessor is a source-to-source

Well you can redefine keywords:

#define private public
#define protected public
#include <....>

Well it is a C++ hack - but I guess you get the drift.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Hyman Rosen]

Martin Krischik wrote:
> Well you can redefine keywords:
> 
> #define private public
> #define protected public
> #include <....>
> 
> Well it is a C++ hack - but I guess you get the drift.

To what purpose? Unless every single module which includes the
affected structures is recompiled, the result is a program with
undefined behavior, since it has violated the one-definitiuon rule.

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Craig Carey]

On Fri, 14 Nov 2003 11:16:22 +0100, Dmitry A. Kazakov wrote:
>On Fri, 14 Nov 2003 10:44:47 +0100, Vinzent 'Gadget' Hoefler wrote:
...
>>>On Fri, 14 Nov 2003 10:04:02 +1300
>>>Craig Carey <research@ijs.co.nz> wrote:
...
>>>> Ada 95 could be enhanced so that specified record fields could be
>>>> read-only.
>>
>>BTW, this is a neat idea. OTOH, for this approach to be practical
>>someone *must* have write access.
>
>1. Not always. We already have constant "record" fields in Ada. They
>are called discriminants.
>2. Constructor
...

1. Perhaps Mr Kazakov would priovide more details about the
 "Not Always" comment.It could be the default assignment of a pointer
  pointing into the interior of the same record.

2. Since Ada 95 lacks read-only fields, so would the "We" of the
  message I reply to.

A solution is to replace field "X : Integer" with

  X  : Integer_Access_Constant_Ptr
  XA : Private_Type_Supposedly_Integer;

Maybe the record has to the tagged to get the pointer initialized.
It is awkward inide of the package and outside too.

All external statements like this

       "if X.Denom /= Y.Denom .."

would be changed to

       "if X.Denom.all /= Y.Denom.all".

A better solution might be to make every field be read-only, and
then remove read-only statuse from fields only by one.

The package is rewritten so that its procedures expect an
"access constant" pointer to the record, instead of record.

   Data_ZZZ : aliased P.D_Priv_Rec;      --  Real record, don't use
   Data     : constant P.D_Type := Data_ZZZX'Access;  --  100% R/O

To write to a single field, dereference a pointer function. E.g.:

   Ptr_Field_Bigness (X).all := (3, 2);

ObjectAda compiler easily finds that discriminants are not the
hoped for read-only feature:

   -------------
   type num is
      record
         Num, Den : Integer;
      end record;

   type Arbitrary (Pool_Const : Num) is      --  <-- Invalid Ada
      record
         Arb   : Num;
      end record;

      --   ObjectAda 7.2.2 says  "Error: LRM:3.7(9), the subtype of a
      --    discriminant must be a discrete or access subtype"
      --  [or defined using "access subtype_mark"].
   -------------

Discrimannts are not actually read-only since they don't need to be
supplied when the variable is declared but can be changed simply
afterwards. It does not sound like something that is read-only.


Craig Carey
Ada mailing lists: http://www.ijs.co.nz/ada_95.htm

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Dmitry A. Kazakov]

On Tue, 25 Nov 2003 23:06:52 +1300, Craig Carey <research@ijs.co.nz>
wrote:

>On Fri, 14 Nov 2003 11:16:22 +0100, Dmitry A. Kazakov wrote:
>>On Fri, 14 Nov 2003 10:44:47 +0100, Vinzent 'Gadget' Hoefler wrote:
>...
>>>>On Fri, 14 Nov 2003 10:04:02 +1300
>>>>Craig Carey <research@ijs.co.nz> wrote:
>...
>>>>> Ada 95 could be enhanced so that specified record fields could be
>>>>> read-only.
>>>
>>>BTW, this is a neat idea. OTOH, for this approach to be practical
>>>someone *must* have write access.
>>
>>1. Not always. We already have constant "record" fields in Ada. They
>>are called discriminants.
>>2. Constructor
>...
>
>1. Perhaps Mr Kazakov would priovide more details about the
> "Not Always" comment.

I treat "someone" [having access] as a user of the type. This
"someone" need not to have write access. The whole idea of constant
members is to deprive it from that access. As for Ada improvement,
then it is absolutely clear how to make read-only fields without
having write access. They have to be publicly constants and privately
not. Further, with a better ADT one could make a next step and to
allow an implementation of record fields using primitive operations =
abstract record interface.

>It could be the default assignment of a pointer
>pointing into the interior of the same record.

Yep, this too.

[...]

>Discrimannts are not actually read-only since they don't need to be
>supplied when the variable is declared but can be changed simply
>afterwards. It does not sound like something that is read-only.

I think there is a confusion here. To have a read-only field is not a
property of a variable, but of a value of. It is a [sub-]type which
interface does not allow to change the field. This does not prevent us
from changing the whole value. Yet the field is still read-only. If
you are going to object, then consider a case when the scope of the
variable is leaved and then a new variable is created in another scope
with a value having all the same fields, but the read-only one
changed. The effect would be exactly same as one of changing the
field!

If the goal is to ensure that all values a variable may hold, shall
have *same* field, then it is another thing. For this one should
constrain the corresponding type. Partially it can be done using
discriminants.

Partially, because, yes as you pointed out, not everything may have a
discriminant and not all types are allowed to be ones of
discriminants.

BTW, I by no means against improvement of Ada! (:-))

--
Regards,
Dmitry Kazakov
http://www.dmitry-kazakov.de

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Dave Thompson]

On Fri, 21 Nov 2003 16:34:17 +0100, Martin Krischik
<krischik@users.sourceforge.net> wrote:

> Dave Thompson wrote:
> 
> > There's nothing you can do with the C preprocessor that can't be done
> > directly in source -- because the preprocessor is a source-to-source
> 
> Well you can redefine keywords:
> 
> #define private public
> #define protected public
> #include <....>
> 
> Well it is a C++ hack - but I guess you get the drift.
> 
If you do that for a *standard* header, as the <> implies but does not
require, it's technically illegal: C 7.1.2, C++ 17.4.3.1.1p2. But even
where it works anyway, or for a header where it's legal, you can
accomplish the same thing by writing out (desired declarations etc.
from) the contents of the include-d file changed as specified. That's
(one case of) what I meant by "directly in [your] source".

- David.Thompson1 at worldnet.att.net

Re: C's trikery semantic opens up backdoor in new Linux kernel

[Hyman Rosen]

Dave Thompson wrote:
 > you can accomplish the same thing by writing out (desired declarations etc.
> from) the contents of the include-d file changed as specified.

Note that a Standard C++ compiler is not required to represent
such a modified structure in the same way as the original. If
the class name for the modified class is the same as the original,
and the program includes both, the behavior is undefined. If you
attempt to examine an object of the original type using a pointer
to the new type, the behavior is undefined.

In Standard C++, the technical meaning of "undefined behavior" is
that if an operation with undefined behavior is ever encountered
by a program, the behavior of the entire program is completely
unspecifed by the standard, even for things that happen before
that operation. Violating the One-Definition Rule (that is, the
definition of a type or function must be exactly the same throughout
an entire program, when the language permits a definition to appear
more than once) makes a program undefined as well.