Google is collaborating with other members of the OAuth community to
address this issue. No Google services using OAuth have been
identified as affected at this point, and we have not received any
reports about this issue. Some Google services use other variants of
OAuth that are not affected. For the few websites that use OAuth,
Google now displays a warning message to users on the OAuth approval
page, but will still allow the user to approve the request. Once the
OAuth community has identified a fix, we will remove the warning
message for websites that support this fix. Please note that AuthSub
does not contain this vulnerability, and we will continue to support
AuthSub without any changes.
I thought the actual data access requests had to be signed by a key
that has to match the token. Perhaps that check isn't implemented at
Google. It would be useful to know.
It is recommended that Service Providers immediately implement
appropriate monitoring to detect exploit attempts, says
http://oauth.net/advisories/2009-1 . Eric, do you have any advise if a
ISP should monitor this or is it ok to do nothing?
@David:
The exploit involves legitimate transactions/data signing.
The token process is initiated (and completed) by evil.com.
In short, the vulnerability arises from a social
engineering scenario where evil.com tricks GoodUser
into authorizing access to his/her data. In actuality,
GoodUser thinks he/she is granting access to
good.com.
@Voelspriet:
I'm not sure what you mean by ISP monitoring?
I will say that it's not Google's position to give any advise
or recommendations to SPs. That is something that
should be (and will be) left up to the OAuth community as they
finalize on a solution. I suspect there will be a number
of follow up posts on the oauth.net security advisory
and its mailing list: http://groups.google.com/group/oauth.
Eric
On Apr 23, 9:59 am, Voelspriet <voelspr...@gmail.com> wrote:
> It is recommended that Service Providers immediately implement
> appropriate monitoring to detect exploit attempts, sayshttp://oauth.net/advisories/2009-1. Eric, do you have any advise if a
> ISP should monitor this or is it ok to do nothing?
I think David was under the impression that the part of the process where an
authorized request token turns into an access token also required signing
with the app's key/secret. I was also under that impression, so I'm also not
sure how evil.com could use a request token handed out to good.com without
knowing good.com's credentials as well. If you could please clarify for all
of us, I'd appreciate it.
I'm at work, so don't have time to look at the spec, but perhaps that part
of the exchange isn't signed the same way? Or it assumes that the request
token was already signed, so it just assumes that the authorized request
token is valid? I would think that if that's the case, the solution is
pretty simple - require that the request token also be signed at the time of
upgrade. It would require all consumers to update their code to do so, but I
believe at least in the case of Google as the provider, they'd just have to
install an update to their libraries, assuming Google quickly provides one.
On Thu, Apr 23, 2009 at 11:15 AM, Eric (Google) <api.e...@google.com> wrote:
> @David:
> The exploit involves legitimate transactions/data signing.
> The token process is initiated (and completed) by evil.com.
> In short, the vulnerability arises from a social
> engineering scenario where evil.com tricks GoodUser
> into authorizing access to his/her data. In actuality,
> GoodUser thinks he/she is granting access to
> good.com.
> @Voelspriet:
> I'm not sure what you mean by ISP monitoring?
> I will say that it's not Google's position to give any advise
> or recommendations to SPs. That is something that
> should be (and will be) left up to the OAuth community as they
> finalize on a solution. I suspect there will be a number
> of follow up posts on the oauth.net security advisory
> and its mailing list: http://groups.google.com/group/oauth.
> Eric
> On Apr 23, 9:59 am, Voelspriet <voelspr...@gmail.com> wrote:
> > It is recommended that Service Providers immediately implement
> > appropriate monitoring to detect exploit attempts, sayshttp://
> oauth.net/advisories/2009-1. Eric, do you have any advise if a
> > ISP should monitor this or is it ok to do nothing?
> I think David was under the impression that the part of the process where an
> authorized request token turns into an access token also required signing
> with the app's key/secret. I was also under that impression, so I'm also not
> sure how evil.com could use a request token handed out to good.com without
> knowing good.com's credentials as well. If you could please clarify for all
> of us, I'd appreciate it.
> I'm at work, so don't have time to look at the spec, but perhaps that part
> of the exchange isn't signed the same way? Or it assumes that the request
> token was already signed, so it just assumes that the authorized request
> token is valid? I would think that if that's the case, the solution is
> pretty simple - require that the request token also be signed at the time of
> upgrade. It would require all consumers to update their code to do so, but I
> believe at least in the case of Google as the provider, they'd just have to
> install an update to their libraries, assuming Google quickly provides one.
> Mike.
> On Thu, Apr 23, 2009 at 11:15 AM, Eric (Google) <api.e...@google.com> wrote:
> > @David:
> > The exploit involves legitimate transactions/data signing.
> > The token process is initiated (and completed) by evil.com.
> > In short, the vulnerability arises from a social
> > engineering scenario where evil.com tricks GoodUser
> > into authorizing access to his/her data. In actuality,
> > GoodUser thinks he/she is granting access to
> > good.com.
> > @Voelspriet:
> > I'm not sure what you mean by ISP monitoring?
> > I will say that it's not Google's position to give any advise
> > or recommendations to SPs. That is something that
> > should be (and will be) left up to the OAuth community as they
> > finalize on a solution. I suspect there will be a number
> > of follow up posts on the oauth.net security advisory
> > and its mailing list:http://groups.google.com/group/oauth.
> > Eric
> > On Apr 23, 9:59 am, Voelspriet <voelspr...@gmail.com> wrote:
> > > It is recommended that Service Providers immediately implement
> > > appropriate monitoring to detect exploit attempts, sayshttp://
> > oauth.net/advisories/2009-1. Eric, do you have any advise if a
> > > ISP should monitor this or is it ok to do nothing?
> I think David was under the impression that the part of the process where an
> authorized request token turns into an access token also required signing
> with the app's key/secret. I was also under that impression, so I'm also not
Actually I was thinking more about the data accesses (e.g. fetch a
calendar feed for a user from Google).
I had assumed that such a request needed a) a token and b) to be
signed, and that the token had to
match the signing key, that check being done by Google. Therefore
acquiring a token, regardless of
how it was done, gives an attacker no benefits if they don't have the
key (which they don't since if
they did it'd be safe to assume they have all the tokens as well and
wouldn't need to mount this
particular attack). Thus a token issued deceptively for good.com's
access, to evil.com would be
worthless to evil.com because their feed fetches would fail the
signature check.
Anyway, I trust the folks who have worked on this and I am sure the
vulnerability is valid, I just wanted to clarify my thinking here.
The idea, as far as I understand, is that the user's information on
the service provider could be accessed by *another user* registered
with the good consumer. E.g., if we both have Picasa photo sets that
we allow goodphotoeditor.com to access on our behalf, I could trick
you into following a link that would result in me having access to
your Picasa photos.
--peter keane
On Apr 23, 2:25 pm, David Boreham <da...@boreham.org> wrote:
> > I think David was under the impression that the part of the process where an
> > authorized request token turns into an access token also required signing
> > with the app's key/secret. I was also under that impression, so I'm also not
> Actually I was thinking more about the data accesses (e.g. fetch a
> calendar feed for a user from Google).
> I had assumed that such a request needed a) a token and b) to be
> signed, and that the token had to
> match the signing key, that check being done by Google. Therefore
> acquiring a token, regardless of
> how it was done, gives an attacker no benefits if they don't have the
> key (which they don't since if
> they did it'd be safe to assume they have all the tokens as well and
> wouldn't need to mount this
> particular attack). Thus a token issued deceptively for good.com's
> access, to evil.com would be
> worthless to evil.com because their feed fetches would fail the
> signature check.
> Anyway, I trust the folks who have worked on this and I am sure the
> vulnerability is valid, I just wanted to clarify my thinking here.
On Apr 23, 1:46 pm, pkeane <pjke...@gmail.com> wrote:
> The idea, as far as I understand, is that the user's information on
> the service provider could be accessed by *another user* registered
> with the good consumer. E.g., if we both have Picasa photo sets that
> we allow goodphotoeditor.com to access on our behalf, I could trick
> you into following a link that would result in me having access to
> your Picasa photos.
Hmm...if the only way to execute this attack is to use the good
consumer as a proxy then it's not quite as bad as it could be
since, at least in my service's case, they would need to know the
target's Google id as well. We take steps to ensure that the id we
have
stored matches the token, to reduce support problems with
users who got their husband's account's token.
Eric - it would be very useful if you could update the Google OAuth
documentation at:
http://code.google.com/apis/accounts/docs/OAuth.html with a link to the Oauth advisory page and an explanation of why
you're showing the "This website has not been configured to send
requests securely." warning.
Thanks, Gabor
On Apr 23, 12:13 am, "Eric (Google)" <api.e...@google.com> wrote:
> Google is collaborating with other members of the OAuth community to
> address this issue. No Google services using OAuth have been
> identified as affected at this point, and we have not received any
> reports about this issue. Some Google services use other variants of
> OAuth that are not affected. For the few websites that use OAuth,
> Google now displays a warning message to users on the OAuth approval
> page, but will still allow the user to approve the request. Once the
> OAuth community has identified a fix, we will remove the warning
> message for websites that support this fix. Please note that AuthSub
> does not contain this vulnerability, and we will continue to support
> AuthSub without any changes.
