Hacker News Reader

Comment by olalonde | Hacker News Reader

But who gives DDL/SQL access to untrusted users? It seems to be a rather unusual scenario.

It is AWS redshift - a Postgres compatible SQL service. You interact with it via SQL.

Yes, but generally you don’t give SQL access to the internet or completely unauthenticated users.

Any user could likely cause issues for Redshift by running completely nuts queries that exhaust all the servers resources. Is “shit SQL” a bounty worthy issue

I see, I misunderstood.

Yes, having the power to crash your own instance might not be a security issue per se.

Good point.

The problem I know of is a bit different, in that it is a direct and immediate server crash. It's not a denial of service by making the cluster slow. It's run-query, crash-server.

You are right of course that any normal user can issue crazy queries which hog resources, and hammer performance.

I would just reach out to AWS directly: why go through hacker one?

They have a direct email and are responsive. If the issue meets their criteria then you get a payout.

I Googled for AWS bug bounty programs.

I found nothing.

Do you have a URL of any kind, for more information about this, including contacts?

https://aws.amazon.com/security/vulnerability-reporting/

I wouldn’t expect a bounty for something like this, but I believe the above is the correct avenue for reporting it.

aws-security@amazon.com - it’s very clearly the first result when you search “AWS security report”.

A scenario where as an attacker:

- You have raw access to the DB

- You don't have enough privileges to get something more valuable than crashing the DB

- You don't care to get noticed/caught

Does sound pretty unlikely

Just as an aside, I don't think your query is directly logged.

I've not actually checked, so I don't know, but knowing how logging works on RS, I think the cluster crashing will mean your killer query is not logged.

Your session will have been logged by the time the cluster crashes. OTOH, maybe you were logged in for some time first, or there's connection pooling, or you slipped the query into an existing connection's query stream, and so on.

Actually, thinking about it, I think you could reduce the problem to a single query, rather than two, which would help cover tracks.

I assume the exploit only takes down your own instance, not the whole AWS redshift service. If it's the latter, it should obviously be rewarded with big $.

Yes and yes :-)

“Yes” as in “yes, my exploit takes down all of redshift”? Or “yes” as in “yes it only takes down my instance” ?

> I assume the exploit only takes down your own instance, not the whole AWS redshift service.

First yes for this.

> If it's the latter, it should obviously be rewarded with big $.

Second yes for this.

:-)

Reply on news.ycombinator.com