Re: The substituability test is breaking the encapsulation
On Feb 25, 2019, at 1:28 PM, fo...@univ-mlv.fr wrote:
>
>> So encapsulation, controlled by user choice, provides adequate
>> control over this corner case in op== semantics.
>
> it's unforgeable but you can still guess the content of 'i' using a timing
> attack ? no ?
Yes.
These points are not unique to values. They are well known
for non-values. If you use value types as security tokens,
there's a set of best practices you need to follow.
Example this kind of thing today:
class PasswordWrapper {
private String password;
public PasswordWrapper(String password) { … }
boolean checkPassword(String attempt) { … }
// and an anti-pattern:
enum Status { GOT_IT, LOWER, HIGHER, HOTTER, COLDER, … }
boolean Status sniffPassword(String attempt) { … }
}
The timing attacks are equivalent to the presence of a
sniffPassword method. None of this depends particularly
on value-ness.
The new thing you have noticed, Remi, is that value*
classes lack a routine means of forge prevention, the
identity wristband. This is the same thing that int lacks
and String lacks (as usually employed) and VBCs lack
(if clients follow the VBC rules). Does this mean that
ints and strings and VBCs are less secure than opaque
objects? Yes, I suppose they are, by some measures
of security.
If you want a really insecure value, make it Comparable,
so that it can be guessed by binary search. Does this
mean Comparable is insecure?
— John
Re: The substituability test is breaking the encapsulation
In the absolute worst case, we could give up on encapsulation of fields. I
wouldn’t want to do that, but right now, I’d rather do that than accept a
non-reflexive ==. But I’m sure there’s a better alternative — let’s find it.
> On Feb 25, 2019, at 4:23 PM, fo...@univ-mlv.fr wrote:
>
> What i'm saying is that using a component wise test as == as a security
> implication, something i was not aware before thinking about it,
> and something i'm sure our users don't want to be aware of.
>
> Having two different meanings for "encapsulation", one for references and one
> for values is possible a solution, but it's moving the problem to the users,
> by saying, you will have to be careful enough to know that class
> encapsulation and value class encapsulation works differently.
> The first part of the moto is "code like a class" and not "code like a class
> but beware because the encapsulation model is different".
>
> It also makes the implementation of an interface by to a value class more
> hazardous, by example, can a panama Address can be implemented by a value
> class ? The answer is not easy because the encapsulation model is leaky.
>
>> if the constructor is not accessible to the attacker
> so a serializable value class is a security liability ?
>
> And a component wise test is also prone to timing attacks, you can guess the
> value of the fields far faster than checking all combinations.
>
> Rémi
>
> - Mail original -
>> De: "Brian Goetz"
>> À: "Remi Forax"
>> Cc: "valhalla-spec-experts"
>> Envoyé: Lundi 25 Février 2019 15:32:18
>> Objet: Re: The substituability test is breaking the encapsulation
>
>> Good — let’s drill into this.
>>
>> At a high level, you’re saying there’s a tension between encapsulation and a
>> state-based comparison primitive; that the state-based comparison is a side
>> channel through which encapsulated state may be leaked. That’s true. (Just
>> as
>> there is a tension between “values are objects” and “objects have identity”.)
>>
>> To pick up on John’s note from v-dev over the weekend, value-objects are more
>> easily _forgeable_ than identity-objects. There are infinitely many possible
>> java.lang.Integers, because of the unique-per-instance identity; there are
>> only
>> finitely many instances of
>>
>> value class IntWrapper { public int i; }
>>
>> and, given access to the constructor, you can construct them all, and readily
>> stamp out whatever instance you like, and it is just as good as all other
>> instances with that state.
>>
>> We want value to have as many of the things that classes have, within the
>> constraints that values eschew identity. So they can’t have mutability or
>> layout polymorphism. But they can have methods, fields, constructors, type
>> variables, etc. And we’d like for “encapsulation” to be in this set.
>>
>> As a trivial observation, the concern you raise here goes away if the
>> constructor is not accessible to the attacker. That suggests there are at
>> least two paths to plugging this leak; tighten state-based comparison, or
>> require classes that want to encapsulate their state to also encapsulate the
>> constructors that can produce arbitrary state.
>>
>> So, rather than blaming ==, or blaming encapsulation, let’s set out some
>> expectations for how we want to use encapsulation in values.
>>
>> (I think this problem may be related to another problem — that of when a
>> client
>> should be allowed to use `withfield`. For an unencapsulated class like
>> Point,
>> where the ctor expresses no constraints, it seems desirable to let clients
>> say
>> “p __with x = 2” (with whatever syntax), without making the author expose yet
>> more accessor methods, but clearly for encapsulated values, that’s not OK.)
>>
>>> On Feb 25, 2019, at 5:11 AM, Remi Forax wrote:
>>>
>>> Hi all,
>>> there is another issue with making the component wide test available for any
>>> value types, it's leaking the implementation.
>>>
>>> Let say we have this class:
>>>
>>> public value class GuessANumber {
>>> private final int value;
>>>
>>> public GuessANumber(int value) {
>>> this.value = value;
>>> }
>>>
>>> public enum Response { LOWER, GREATER, FOUND };
>>>
>>> public Response guess(int guess) {
>>> if (value < guess) {
>>> return Response.LOWER;
>>> }
>>> if (value > guess) {
>>> return Response.GREATER;
>>> }
>>> return Response.FOUND;
>>> }
>>>
>>> public static GuessANumber random(int seed) {
>>> return new GuessANumber(new Random(seed).nextInt(1024));
>>> }
>>> }
>>>
>>> you can naively think that if we have an an instance of GuessANumber
>>> var number = GuessANumber.random(0);
>>> you have can not get the value of the private field of that instance,
>>> but using == you can find it because you can use == to test if number is
>>> substituable to a user created GuessANumber.
>>>
>>> here is how to find the value without using the method guess()
>>>
Re: The substituability test is breaking the encapsulation
- Mail original -
> De: "John Rose"
> À: "Brian Goetz"
> Cc: "Remi Forax" , "valhalla-spec-experts"
>
> Envoyé: Lundi 25 Février 2019 21:37:00
> Objet: Re: The substituability test is breaking the encapsulation
> On Feb 25, 2019, at 6:32 AM, Brian Goetz wrote:
>> …
>> To pick up on John’s note from v-dev over the weekend, value-objects are more
>> easily _forgeable_ than identity-objects. There are infinitely many possible
>> java.lang.Integers, because of the unique-per-instance identity; there are
>> only
>> finitely many instances of
>>
>>value class IntWrapper { public int i; }
>>
>> and, given access to the constructor, you can construct them all, and readily
>> stamp out whatever instance you like, and it is just as good as all other
>> instances with that state.
>
> My current favorite metaphor for explaining the difference
> between value* objects and reference* objects is the one
> you coined, Brian, of the little band placed around the infant's
> wrist just after birth. Similarly the JVM adds such a unique
> extra identity* (what else do you call it?) to every Integer but
> not to any int. Values are not values because they have
> something different from objects, but because they don't
> have the wristband; you can't tell them apart anymore,
> compared to objects which always carry their little wristband
> around. (Metaphor failures: We don't use infant wristbands
> to *tell infants apart*. And the infant eventually loses the
> wristband. Tattoo? Let's not; besides those are forgeable.
> Regardless, the wristband is helpful.)
>
> So if an implementor wants every new value to be not-same*
> to every other new value, the implementor of the value* class
> can just add a wristband. That is:
>
>>value class UnforgeableIntWrapper {
>> public int i;
>> private Object wristband = new Object(); }
>
> And done, I hope.
>
> Does the JVM have anything to add here? I don't think so.
> If we were to create unforgeable value objects as a third
> or fourth kind of type, this is the implementation we'd use.
>
> So encapsulation, controlled by user choice, provides adequate
> control over this corner case in op== semantics.
it's unforgeable but you can still guess the content of 'i' using a timing
attack ? no ?
>
> — John
Rémi
Re: The substituability test is breaking the encapsulation
What i'm saying is that using a component wise test as == as a security
implication, something i was not aware before thinking about it,
and something i'm sure our users don't want to be aware of.
Having two different meanings for "encapsulation", one for references and one
for values is possible a solution, but it's moving the problem to the users, by
saying, you will have to be careful enough to know that class encapsulation and
value class encapsulation works differently.
The first part of the moto is "code like a class" and not "code like a class
but beware because the encapsulation model is different".
It also makes the implementation of an interface by to a value class more
hazardous, by example, can a panama Address can be implemented by a value class
? The answer is not easy because the encapsulation model is leaky.
> if the constructor is not accessible to the attacker
so a serializable value class is a security liability ?
And a component wise test is also prone to timing attacks, you can guess the
value of the fields far faster than checking all combinations.
Rémi
- Mail original -
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 25 Février 2019 15:32:18
> Objet: Re: The substituability test is breaking the encapsulation
> Good — let’s drill into this.
>
> At a high level, you’re saying there’s a tension between encapsulation and a
> state-based comparison primitive; that the state-based comparison is a side
> channel through which encapsulated state may be leaked. That’s true. (Just
> as
> there is a tension between “values are objects” and “objects have identity”.)
>
> To pick up on John’s note from v-dev over the weekend, value-objects are more
> easily _forgeable_ than identity-objects. There are infinitely many possible
> java.lang.Integers, because of the unique-per-instance identity; there are
> only
> finitely many instances of
>
>value class IntWrapper { public int i; }
>
> and, given access to the constructor, you can construct them all, and readily
> stamp out whatever instance you like, and it is just as good as all other
> instances with that state.
>
> We want value to have as many of the things that classes have, within the
> constraints that values eschew identity. So they can’t have mutability or
> layout polymorphism. But they can have methods, fields, constructors, type
> variables, etc. And we’d like for “encapsulation” to be in this set.
>
> As a trivial observation, the concern you raise here goes away if the
> constructor is not accessible to the attacker. That suggests there are at
> least two paths to plugging this leak; tighten state-based comparison, or
> require classes that want to encapsulate their state to also encapsulate the
> constructors that can produce arbitrary state.
>
> So, rather than blaming ==, or blaming encapsulation, let’s set out some
> expectations for how we want to use encapsulation in values.
>
> (I think this problem may be related to another problem — that of when a
> client
> should be allowed to use `withfield`. For an unencapsulated class like Point,
> where the ctor expresses no constraints, it seems desirable to let clients say
> “p __with x = 2” (with whatever syntax), without making the author expose yet
> more accessor methods, but clearly for encapsulated values, that’s not OK.)
>
>> On Feb 25, 2019, at 5:11 AM, Remi Forax wrote:
>>
>> Hi all,
>> there is another issue with making the component wide test available for any
>> value types, it's leaking the implementation.
>>
>> Let say we have this class:
>>
>> public value class GuessANumber {
>> private final int value;
>>
>> public GuessANumber(int value) {
>>this.value = value;
>> }
>>
>> public enum Response { LOWER, GREATER, FOUND };
>>
>> public Response guess(int guess) {
>>if (value < guess) {
>> return Response.LOWER;
>>}
>>if (value > guess) {
>> return Response.GREATER;
>>}
>>return Response.FOUND;
>> }
>>
>> public static GuessANumber random(int seed) {
>>return new GuessANumber(new Random(seed).nextInt(1024));
>> }
>> }
>>
>> you can naively think that if we have an an instance of GuessANumber
>> var number = GuessANumber.random(0);
>> you have can not get the value of the private field of that instance,
>> but using == you can find it because you can use == to test if number is
>> substituable to a user created GuessANumber.
>>
>> here is how to find the value without using the method guess()
>> System.out.println(IntStream.range(0, 1024).filter(n -> new GuessANumber(n)
>> ==
>> number).findFirst());
>>
> > Rémi
Re: The substituability test is breaking the encapsulation
On Feb 25, 2019, at 6:32 AM, Brian Goetz wrote:
> …
> To pick up on John’s note from v-dev over the weekend, value-objects are more
> easily _forgeable_ than identity-objects. There are infinitely many possible
> java.lang.Integers, because of the unique-per-instance identity; there are
> only finitely many instances of
>
>value class IntWrapper { public int i; }
>
> and, given access to the constructor, you can construct them all, and readily
> stamp out whatever instance you like, and it is just as good as all other
> instances with that state.
My current favorite metaphor for explaining the difference
between value* objects and reference* objects is the one
you coined, Brian, of the little band placed around the infant's
wrist just after birth. Similarly the JVM adds such a unique
extra identity* (what else do you call it?) to every Integer but
not to any int. Values are not values because they have
something different from objects, but because they don't
have the wristband; you can't tell them apart anymore,
compared to objects which always carry their little wristband
around. (Metaphor failures: We don't use infant wristbands
to *tell infants apart*. And the infant eventually loses the
wristband. Tattoo? Let's not; besides those are forgeable.
Regardless, the wristband is helpful.)
So if an implementor wants every new value to be not-same*
to every other new value, the implementor of the value* class
can just add a wristband. That is:
>value class UnforgeableIntWrapper {
> public int i;
> private Object wristband = new Object(); }
And done, I hope.
Does the JVM have anything to add here? I don't think so.
If we were to create unforgeable value objects as a third
or fourth kind of type, this is the implementation we'd use.
So encapsulation, controlled by user choice, provides adequate
control over this corner case in op== semantics.
— John
