View mode: basic / threaded / horizontal-split · Log in · Help
February 12, 2007
Security Risk?
When a procedure gives a class instance for processing to a module mod

 class CPP{ int i; /+ ... +/}
 auto d= new CPP;
 d= mod.process( d);

that processing is currently able to hide additional data and methods 
in that class instance.

Is somebody able to show that such hidden data and methods cannot be 
used to endanger the whole system?

-manfred
February 12, 2007
Re: Security Risk?
Manfred Nowak wrote:
> When a procedure gives a class instance for processing to a module mod
> 
>   class CPP{ int i; /+ ... +/}
>   auto d= new CPP;
>   d= mod.process( d);
> 
> that processing is currently able to hide additional data and methods 
> in that class instance.
> 
> Is somebody able to show that such hidden data and methods cannot be 
> used to endanger the whole system?

D is a systems language.  Using pointers and such, any method is free to 
randomly overwrite application memory if it really wants to.


Sean
February 12, 2007
Re: Security Risk?
Sean Kelly wrote

> D is a systems language.  Using pointers and such, any method is
> free to randomly overwrite application memory if it really wants
> to. 

That is not what I mean. Overwriting of memory used by the application 
would cause loss of data, unless the data is compressible. And loss of 
data would cause malfunctioning.

But with D one does not need to overwrite memory. D seems to be able to 
attach data to a class instance without letting you know about that. 
So: no malfunctioning until it is triggered somehow.

Even if the data of the application is incompressible, one seems unable 
to detect the attached data, because even if one requires to have that 
incompressible data returned unchanged and it comes back unchanged, 
even then there might be data attached.

If my fears turn out to be true, then D has an integrated capability 
for supporting trojans.

-manfred
February 12, 2007
Re: Security Risk?
Manfred Nowak wrote:
> When a procedure gives a class instance for processing to a module mod
> 
>   class CPP{ int i; /+ ... +/}
>   auto d= new CPP;
>   d= mod.process( d);
> 
> that processing is currently able to hide additional data and methods 
> in that class instance.
> 
> Is somebody able to show that such hidden data and methods cannot be 
> used to endanger the whole system?
> 
> -manfred

What makes D special in this regard?  Can't you do it with C++ just as 
easily?  (Not really sure what you mean by 'hiding additional data in 
the instance', but every way I can think of would be just as possible in 
C++.)

--bb
February 12, 2007
Re: Security Risk?
Bill Baxter wrote

> What makes D special in this regard?  Can't you do it with C++
> just as easily?  (Not really sure what you mean by 'hiding
> additional data in the instance', but every way I can think of
> would be just as possible in C++.)

Thank you for the hint.

Meanwhile I have checked D and C++ for that risk---and yes also C++ is 
vulnerable. D got it slightly better.

The risk stems from the possibility to cast instances up and down the 
derivation tree.

Neither C++ nor D seem to have a statement for cutting off some parts 
of the derivation tree.

That is: even if you think you are at a leaf node of the derivation 
tree with your instance, there might be more levels silently present.

This means, that you might be transporting data and methods of an 
attacker through the system.

This means also that an attacker might be able to identify data and 
methods you have marked as being private. And this without being forced 
to dive into system via pointers and such.

The usual language constructs enable such attacks. This somehow 
frightens me.

-manfred
February 13, 2007
Re: Security Risk?
Manfred Nowak wrote:
> Bill Baxter wrote
> 
>> What makes D special in this regard?  Can't you do it with C++
>> just as easily?  (Not really sure what you mean by 'hiding
>> additional data in the instance', but every way I can think of
>> would be just as possible in C++.)
> 
> Thank you for the hint.
> 
> Meanwhile I have checked D and C++ for that risk---and yes also C++ is 
> vulnerable. D got it slightly better.
> 
> The risk stems from the possibility to cast instances up and down the 
> derivation tree.
> 
> Neither C++ nor D seem to have a statement for cutting off some parts 
> of the derivation tree.
> 
> That is: even if you think you are at a leaf node of the derivation 
> tree with your instance, there might be more levels silently present.
> 
> This means, that you might be transporting data and methods of an 
> attacker through the system.
> 
> This means also that an attacker might be able to identify data and 
> methods you have marked as being private. And this without being forced 
> to dive into system via pointers and such.
> 
> The usual language constructs enable such attacks. This somehow 
> frightens me.
> 
> -manfred   

Well, let's take a step back.
As someone mentioned already, D has pointers.  That means if you give 
*any* of my code a chance to run, I can basically do whatever I want.  I 
have access to all the code and data in the current program.  It may not 
be in as easy-to-access form as if you had handed me a pointer to the 
most interesting object on a platter, but it's still all there.

Exploits are almost always about figuring out how to get my arbitrary 
code to be executed by your running program.  If you're *calling* my 
function directly then you're already pwned, as they say.  It's like 
breaking into the burglar's house, dumping your valuables in the middle 
of the floor and then tauting him with "let's see you steal THAT!" as 
you strut out the door.  It's a fait accompli.

--bb
February 13, 2007
Re: Security Risk?
Bill Baxter wrote

> It's like breaking into the burglar's house, dumping your
> valuables in the middle of the floor and then tauting him with
> "let's see you steal THAT!" as you strut out the door.

Yes that is one side of the problem, if one trusts the wrong one.

But the other part is, that after you left the burglars house another 
burglar ties you to the valuables he just stole from someone else and 
by beeing unable to cut that ropes you are doomed to transport the 
stolen valuables for that burglar.

And this part seems to be avoidable.

-manfred
February 13, 2007
Re: Security Risk?
Manfred Nowak wrote:
> Bill Baxter wrote
> 
>> It's like breaking into the burglar's house, dumping your
>> valuables in the middle of the floor and then tauting him with
>> "let's see you steal THAT!" as you strut out the door.
> 
> Yes that is one side of the problem, if one trusts the wrong one.
> 
> But the other part is, that after you left the burglars house another 
> burglar ties you to the valuables he just stole from someone else and 
> by beeing unable to cut that ropes you are doomed to transport the 
> stolen valuables for that burglar.
> 
> And this part seems to be avoidable.
> 
> -manfred

Are you used to programming in Java?  I ask because in Java you can 
build classes that are secure from other classes in the same binary (to 
some degree), but in C, C++, D, you need to do security that is between 
processes.  This means be very careful about user data, never assume 
anything about the data, and never try to run anything the user provides 
as code or as an expression.

The Java way means that you can pull a compiled object from a database 
and run its methods with reflection.  I don't think this is ever safe in 
C++ or D unless you know what all the classes do.

C++, C, D, can't do 'class security' the Java way because they are not 
interpreted languages.  I don't think there is a way around this except 
to compile and run the untrusted code in another process -- and even 
this is a bad idea if you don't trust the code.

But my understanding of Java security in this regard is somewhat simple 
since I've never actually implemented much Java that needed or tried to 
be secure.

Kevin
Top | Discussion index | About this forum | D home