www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Security Risk?

reply Manfred Nowak <svv1999 hotmail.com> writes:
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
Feb 11 2007
next sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Feb 12 2007
parent Manfred Nowak <svv1999 hotmail.com> writes:
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
Feb 12 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Feb 12 2007
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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
Feb 12 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Feb 12 2007
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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
Feb 12 2007
parent Kevin Bealer <kevinbealer gmail.com> writes:
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
Feb 12 2007