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