Jump to page: 1 2
Thread overview
Intended Security Hole?
Oct 24, 2012
Manfred Nowak
Oct 24, 2012
Chris Cain
Oct 24, 2012
Manfred Nowak
Oct 24, 2012
Justin Whear
Oct 25, 2012
Manfred Nowak
Oct 25, 2012
Maxim Fomin
Oct 25, 2012
Manfred Nowak
Oct 25, 2012
Maxim Fomin
Oct 25, 2012
Manfred Nowak
Oct 25, 2012
Maxim Fomin
Oct 25, 2012
Manfred Nowak
Oct 25, 2012
Maxim Fomin
October 24, 2012
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
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
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
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
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
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
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
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
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
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