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
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 reply "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
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 "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
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Maxim Fomin wrote:


     b= d2;


 What is wrong here?


The slight change in behavior might be unexpected and not intended for 
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. 


Variables can not be inhereted, only types. It seems to be euphemistic, 
to name "information steeling from" or "information changing of" a 
variable  by the conceptual term "inheritance".

-manfred
Oct 25 2012
parent reply "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;


 What is wrong here?


 The slight change in behavior might be unexpected and not 
 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.


 Variables can not be inhereted, only types. It seems to be 
 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
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Maxim Fomin wrote:


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


Do you really mean by this, that "aspect programming" is impossible in 
D?
Or that marking `final' is enough?


 provide an example how you can do this.


I was in fear and posted an approach. But I was not sure. 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
Oct 25 2012
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.


 Do you really mean by this, that "aspect programming" is 
 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.


 I was in fear and posted an approach. But I was not sure. 
 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 reply Manfred Nowak <svv1999 hotmail.com> writes:
Maxim Fomin wrote:


 Why now you are complaining about this?


Because this is the learn group and I did not realize, that the 
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
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?


 Because this is the learn group and I did not realize, that the
 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