Prev: Getting rid of "if condition" by some math equation.
Next: String.intern() (Was: create a string of <n> equal chars <c>)
From: ClassCastException on 19 Jul 2010 01:10
On Sun, 18 Jul 2010 11:44:13 +0000, Andreas Leitgeb wrote:

> ClassCastException <zjkg3d9gj56(a)gmail.invalid> wrote:
>> On Sun, 18 Jul 2010 02:54:51 +0000, Andreas Leitgeb wrote:
>>> ClassCastException <zjkg3d9gj56(a)gmail.invalid> wrote:
>>>> On Fri, 16 Jul 2010 22:02:30 +0000, Andreas Leitgeb wrote:
>>>>> I'm still puzzled about that gross hack of creating
>>>>> bridge-methods(&c'tors) rather than letting the jvm recognize
>>>>> certain accessors of privates as still legal. There surely exists
>>>>> some reason for it somewhere out there.
>>>> Security, most likely. The bridge methods can be made by the
>>>> compiler. Recognizing certain outside accesses of private members, at
>>>> the bytecode level, as legal would require relaxing some of the
>>>> stringent checks done by the JVM's bytecode verifier,...
>>> Not relax, just change.
>>> Every class that has inner classes has an attribut "InnerClasses"
>>> defined. If some class attempts to access private parts, the jvm would
>>> just have to check the "InnerClasses" and know if that access would be
>>> granted or denied.
>> Could a hostile class make itself appear to be a member of that set, as
>> far as the verifier was concerned?
>
> It would be the same effort as to fake access to each bridge method. If
> one goes that far (namely monkeying with the original package/zip), one
> could just as well patch away the "private" flag from the target class's
> methods.

My thought was that there might be cases where an attacker can readily
replace one class, but not the other, with a hostile doppelganger.

I don't know how frequent that might be in practice. Probably not very in
the case that one is an inner class of the other, since they'd normally
all be bundled together.

>> There is also the matter that runtime access to all privates would be
>> granted, not just to the particular ones for which javac made synthetic
>> accessors.
>
> On Java level, an inner class can call anything from the outer class.

Yes, I know. Bytecode level was where I was looking, though, since the
choice between synthetic accessors and relaxing the bytecode-level rules
for "private" does not make any difference at the Java level but does at
the bytecode level. You won't therefore find an explanation for why the
choice was made the way it was by looking only at the Java level.

> Also, Java doesn't really protect from sufficiently well-done monkeying
> on class files. Restricting a possibly patched inner class to only the
> bridged methods seems goofy to me, unless it was just the side effect of
> some other goal. A malevolently patched inner class could likely do
> enough bad things with just the bridged methods, already.

Probably, though I expect that to depend on the bridged methods in each
specific case.

If the bridged methods can only mess with one part of the class and not
another, more security-sensitive part, one could argue that that class is
poorly designed because it mixes responsibilities and should be split, as
well.
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Getting rid of "if condition" by some math equation.
Next: String.intern() (Was: create a string of <n> equal chars <c>)