View mode: basic / threaded / horizontal-split · Log in · Help
October 24, 2012
Intended Security Hole?
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
October 24, 2012
Re: Intended Security Hole?
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.
October 24, 2012
Re: Intended Security Hole?
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
October 24, 2012
Re: Intended Security Hole?
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
October 25, 2012
Re: Intended Security Hole?
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
October 25, 2012
Re: Intended Security Hole?
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
October 25, 2012
Re: Intended Security Hole?
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
October 25, 2012
Re: Intended Security Hole?
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.
October 25, 2012
Re: Intended Security Hole?
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
October 25, 2012
Re: Intended Security Hole?
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
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home