www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Intended Security Hole?

reply Manfred Nowak <svv1999 hotmail.com> writes:
From the docs, i.e. function.html:

 Functions without bodies [...] enable implementation to be
 completely hidden from the user of it.

This means also, that the implementation can be changed during runtime by "overriding" with another implementation, which might be malicious. Why is it a good thing to rely on the reputability of an unknwon coder? -manfred
Oct 24 2012
next sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Wednesday, 24 October 2012 at 16:59:11 UTC, Manfred Nowak 
wrote:
 From the docs, i.e. function.html:

 Functions without bodies [...] enable implementation to be
 completely hidden from the user of it.

This means also, that the implementation can be changed during runtime by "overriding" with another implementation, which might be malicious. Why is it a good thing to rely on the reputability of an unknwon coder? -manfred

Missing part of your quote that clarifies your post:
 and that implementation will be provided at the link step.

So, no, the implementation wouldn't be changed during runtime since it must be provided when linking.
Oct 24 2012
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Chris Cain wrote:

 So, no, the implementation wouldn't be changed during runtime 
 since it must be provided when linking.

Thats an expressed intent only. Reason: the linker does not know any thing about the language; the linker would be satisfied if there exists any function the linker can link to ... but the linker would not prohibit any replacement of that function during runtime. Conclusion: until a proof of the imposibility, there might exist cases in which such replacement is possible. Example for a _visible_ hijack: ----------------------------------------------------- private import std.stdio; abstract class Base { void foo(float f); } class Derived1 : Base { void foo(float f) { writefln("f =1= %f", f); } } class Derived2 : Base { void foo(float f) { writefln("f =2= %f", f); } } void main() { Base b; float f = 2.5; auto d1 = new Derived1; b= d1; b.foo( f); // f =1= 2.500000 auto d2= new Derived2; b= d2; b.foo( f); // f =2= 2.500000 } ----------------------------------------- Can be proved that it is impossible to make the assignment `b= d2;' invisible? -manfred
Oct 24 2012
next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Justin Whear wrote:

 is used to create library shims

One might be able to see: this is one of the roots of aspect programming. As a system programming language, D should be able to support this paradigm like aspectC++ shows for c++. Therefore: the answer to the subject is: yes. -manfred
Oct 25 2012
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Maxim Fomin wrote:

     b= d2;


the owner of variable `Base b;'. What is the price ( i.e. coding time, execution time, execution space) the owner of that variable has to pay in the case that she/he want expectable behaviour only and owns the variable `b' but not the source of its type `Base' and has to provide some access to variable `b'? In essence: kills the ability of "aspect programming" the intent of "information hiding"?
 But is not hijacking, it is inheriting. 

to name "information steeling from" or "information changing of" a variable by the conceptual term "inheritance". -manfred
Oct 25 2012
next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Maxim Fomin wrote:

 Then disable behavior by marking class or function as a final.

D? Or that marking `final' is enough?
 provide an example how you can do this.

asked for a proof, that my fear had not cause in reality. Your demand for an example only expresses, that you too are guided by expectations only, not by proofs. - manfred
Oct 25 2012
prev sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Maxim Fomin wrote:

 Why now you are complaining about this?

compiler does conform to the definition of "overload resolution" in function.html#function-inheritance, i.e. my expectation is defined as a bug. - manfred
Oct 25 2012
prev sibling next sibling parent "Justin Whear" <justin economicmodeling.com> writes:
On Wednesday, 24 October 2012 at 21:07:28 UTC, Manfred Nowak 
wrote:
 Chris Cain wrote:

 So, no, the implementation wouldn't be changed during runtime 
 since it must be provided when linking.

Thats an expressed intent only. Reason: the linker does not know any thing about the language; the linker would be satisfied if there exists any function the linker can link to ... but the linker would not prohibit any replacement of that function during runtime.

If the code in question is statically linked, this is not a problem. If it's a shared library which is linked at runtime, then this is actually intended behavior and is used to create library shims. Here's an introduction to the technique: http://www.linuxjournal.com/article/7795
Oct 24 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Wednesday, 24 October 2012 at 21:07:28 UTC, Manfred Nowak 
wrote:
 Chris Cain wrote:

 So, no, the implementation wouldn't be changed during runtime 
 since it must be provided when linking.

Thats an expressed intent only. Reason: the linker does not know any thing about the language; the linker would be satisfied if there exists any function the linker can link to ... but the linker would not prohibit any replacement of that function during runtime. Conclusion: until a proof of the imposibility, there might exist cases in which such replacement is possible. Example for a _visible_ hijack: ----------------------------------------------------- private import std.stdio; abstract class Base { void foo(float f); } class Derived1 : Base { void foo(float f) { writefln("f =1= %f", f); } } class Derived2 : Base { void foo(float f) { writefln("f =2= %f", f); } } void main() { Base b; float f = 2.5; auto d1 = new Derived1; b= d1; b.foo( f); // f =1= 2.500000 auto d2= new Derived2; b= d2; b.foo( f); // f =2= 2.500000 } -----------------------------------------

What is wrong here?
 Can be proved that it is impossible to make the assignment `b= 
 d2;'
 invisible?

Assignment can be "invisible", for ex. if one of functions in _visible_ hijack.d is called from other module with derived class instance when base class instance is expected. But is not hijacking, it is inheriting.
 -manfred

Oct 24 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Thursday, 25 October 2012 at 10:29:12 UTC, Manfred Nowak wrote:
 Maxim Fomin wrote:

     b= d2;


intended for the owner of variable `Base b;'.

Then disable behavior by marking class or function as a final.
 What is the price ( i.e. coding time, execution time, execution 
 space)
 the owner of that variable has to pay in the case that she/he 
 want
 expectable behaviour only and owns the variable `b' but not the 
 source
 of its type `Base' and has to provide some access to variable 
 `b'?

 In essence: kills the ability of "aspect programming" the 
 intent of
 "information hiding"?

 But is not hijacking, it is inheriting.

euphemistic, to name "information steeling from" or "information changing of" a variable by the conceptual term "inheritance". -manfred

What is "information steeling from" and "information changing of" here? You deliberately created derived classes and passed instances of them where base class instances were expected. Why now you are complaining about this? You can use UFCS to do what you want (what I guess you want) because UFCS and virtual functions don't work now: http://dpaste.dzfl.pl/d6eafd71. But be hurry because UFCS admirers who found logic in making every feature work in accordance with UFCS can found this loophole. Also similar effect can be achieved by making functions private. BTW, you started thread with caution regarding replacing implementation of functions without bodies during runtime - please, provide an example how you can do this.
Oct 25 2012
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Thursday, 25 October 2012 at 12:43:34 UTC, Manfred Nowak wrote:
 Maxim Fomin wrote:

 Then disable behavior by marking class or function as a final.

impossible in D? Or that marking `final' is enough?

I mean that if you mark function in Base class as final or private, you can be sure that derived classes do not override functions you want to be non-overriden. So, if virtual call creates problems for you, you can disable it.
 provide an example how you can do this.

Therefore I asked for a proof, that my fear had not cause in reality. Your demand for an example only expresses, that you too are guided by expectations only, not by proofs. - manfred

I definitely not driven by fear whether declared only functions can be hijacked at runtime or not. References to functions with omitted bodies are captured by linker at link-time at implementation-defined and platform specific manner. At linux if you provide multiple definition of same symbol order of arguments does matter. At windows either linker complains about twice defined symbol or reject linking at all - I don't remember. This is not important because linking is typically under of your rather than "unknown coder" control. At runtime it is possible to use system facilities and hacking tools by "unknown coder" to overwrite memory for attacking purposes and may be for changing implementation of some function. But this affects functions with definitions as well as functions with omitted bodies and is unrelated to how one language treats functions without definitions. I don't understand what is an issue: treating declared only functions by dmd, virtual calls or changing function implementation at runtime.
Oct 25 2012
prev sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Thursday, 25 October 2012 at 13:03:30 UTC, Manfred Nowak wrote:
 Maxim Fomin wrote:

 Why now you are complaining about this?

compiler does conform to the definition of "overload resolution" in function.html#function-inheritance, i.e. my expectation is defined as a bug. - manfred

By complaining i implied surprising by behavior not posting messages.
Oct 25 2012