Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Digital Ocean, S3-like space keys can access all your buckets

ideas.digitalocean.com

Post reply on HN
Print view View original

41–50 of 104 posts

Re: In Digital Ocean, S3-like space keys can access all your buckets

#41

Post by sneak »

neom wrote: post #28
belter wrote: post #19

Earlier quoted context omitted.

Some of the comments by DO on that GitHub thread, are really surprising, and disappointing to say the least...

I wrote those comments, fog wasn't using the API as he would have liked, and then this guy starts a bunch of trouble on HN stating that there was a vun on DigitalOcean, and conflated someone using the API incorrectly with us having a security vun. Two things I was trying to (admittedly not very well) say was: if DO did have a security issue, posting it on HN ("DigitalOcean leaks customer data between VMs" huh?) inste…

Wow, this just confirms my belief.

There is precisely zero circumstance where it is ok to give private customer data to another customer.

The fact that you think it had anything to do with an API or how it is used is all anyone needs to know about it.

The idea that warning your customers of your vulnerabilities is "irresponsible" is only true if you care more about revenues than your customers' security.

Re: In Digital Ocean, S3-like space keys can access all your buckets

#42

Post by neom »

ratg13 wrote: post #40
neom wrote: post #28

Earlier quoted context omitted.

I wrote those comments, fog wasn't using the API as he would have liked, and then this guy starts a bunch of trouble on HN stating that there was a vun on DigitalOcean, and conflated someone using the API incorrectly with us having a security vun. Two things I was trying to (admittedly not very well) say was: if DO did have a security issue, posting it on HN ("DigitalOcean leaks customer data between VMs" huh?) inste…

The fact that you think it should be the customers’ responsibility to make sure that DO doesn’t accidentally give your private data away to unknown third parties is an absolutely minblowing take on this matter. I’ve been a DO customer for the better part of a decade, but there is no way that I can continue to be a customer with a company that has such a blasé stance toward security and protecting customer data. If an…

Well first, I've not worked for DigitalOcean in a long time, I left in 2015. I don't really wanna re-hash something from 2013, but again: when you deleted a VM you could click the scrub button or pass the scrub flag in the API when you issued a delete call. It was very well documented and the scrub button wasn't hidden anywhere in the interface. The fog platform wasn't using the scrub flag in their app for whatever reason. As I recall, we did change it to scrub by default shortly after. From what I remember, the reason it wasn't originally default was the zero'ing process tried up a lot of resource on the box and it was hard on the drives and we were very much in startup mode at that time with limited capacity, so it was better to only zero if the customer requests it.

Re: In Digital Ocean, S3-like space keys can access all your buckets

#43

Post by mdpye »

neom wrote: post #42
ratg13 wrote: post #40

Earlier quoted context omitted.

The fact that you think it should be the customers’ responsibility to make sure that DO doesn’t accidentally give your private data away to unknown third parties is an absolutely minblowing take on this matter. I’ve been a DO customer for the better part of a decade, but there is no way that I can continue to be a customer with a company that has such a blasé stance toward security and protecting customer data. If an…

Well first, I've not worked for DigitalOcean in a long time, I left in 2015. I don't really wanna re-hash something from 2013, but again: when you deleted a VM you could click the scrub button or pass the scrub flag in the API when you issued a delete call. It was very well documented and the scrub button wasn't hidden anywhere in the interface. The fog platform wasn't using the scrub flag in their app for whatever r…

You still don't appear to get it though. The fact that there even exists an option (never mind a default) which does not scrub storage between use by different tenants is completely unacceptable in a multi-tenant environment.

Re: In Digital Ocean, S3-like space keys can access all your buckets

#44

Post by dijksterhuis »

sergioisidoro wrote: post #38
drogus wrote: post #36

Wait till you hear that when you generate a DO container registry key it includes a key that gives you access to all of the resources, not only the registry.

Are you saying you have to issue a "god" level API access token to access a single docker (private) image in the Digital Ocean container registry?

The permissions options on the API key are read or write for the whole project.

There is basically no granularity.

Re: In Digital Ocean, S3-like space keys can access all your buckets

#45

Post by drogus »

sergioisidoro wrote: post #38
drogus wrote: post #36

Wait till you hear that when you generate a DO container registry key it includes a key that gives you access to all of the resources, not only the registry.

Are you saying you have to issue a "god" level API access token to access a single docker (private) image in the Digital Ocean container registry?

Yes. And when you generate the container registry token it doesn't mention any of it and it's hard to notice, cause docker auth is base64 encoded. But after you decode the credentials you get a regular DO token that you can use with the API

Re: In Digital Ocean, S3-like space keys can access all your buckets

#46

Post by plagiarist »

neom wrote: post #28
belter wrote: post #19

Earlier quoted context omitted.

Some of the comments by DO on that GitHub thread, are really surprising, and disappointing to say the least...

I wrote those comments, fog wasn't using the API as he would have liked, and then this guy starts a bunch of trouble on HN stating that there was a vun on DigitalOcean, and conflated someone using the API incorrectly with us having a security vun. Two things I was trying to (admittedly not very well) say was: if DO did have a security issue, posting it on HN ("DigitalOcean leaks customer data between VMs" huh?) inste…

Why on Earth would someone have to opt-in to scrubbing with a flag vs. opting out? That's surprising. Is the flag on by default and they specifically opted out before complaining about it?

Re: In Digital Ocean, S3-like space keys can access all your buckets

#47

Post by [deleted] »

richbell wrote: post #34
neom wrote: post #28

Earlier quoted context omitted.

I wrote those comments, fog wasn't using the API as he would have liked, and then this guy starts a bunch of trouble on HN stating that there was a vun on DigitalOcean, and conflated someone using the API incorrectly with us having a security vun. Two things I was trying to (admittedly not very well) say was: if DO did have a security issue, posting it on HN ("DigitalOcean leaks customer data between VMs" huh?) inste…

I do find the claim that "there's nothing irresponsible about full immediate disclosure" to be interesting . https://github.com/fog/fog/issues/2525#issuecomment-31336855

[deleted]

Re: In Digital Ocean, S3-like space keys can access all your buckets

#48

Post by plagiarist »

sneak wrote: post #41
neom wrote: post #28

Earlier quoted context omitted.

I wrote those comments, fog wasn't using the API as he would have liked, and then this guy starts a bunch of trouble on HN stating that there was a vun on DigitalOcean, and conflated someone using the API incorrectly with us having a security vun. Two things I was trying to (admittedly not very well) say was: if DO did have a security issue, posting it on HN ("DigitalOcean leaks customer data between VMs" huh?) inste…

Wow, this just confirms my belief. There is precisely zero circumstance where it is ok to give private customer data to another customer. The fact that you think it had anything to do with an API or how it is used is all anyone needs to know about it. The idea that warning your customers of your vulnerabilities is "irresponsible" is only true if you care more about revenues than your customers' security.

Unless I misunderstood something and one has to explicitly opt out of scrub for this to occur, I agree 100%. This is surprising. And they were mad that a customer thinks this is undesirable?

I was using DO. It is not a serious project but I think I'll be moving on nonetheless.

Re: In Digital Ocean, S3-like space keys can access all your buckets

#49

Post by drogus »

dijksterhuis wrote: post #44
sergioisidoro wrote: post #38

Earlier quoted context omitted.

Are you saying you have to issue a "god" level API access token to access a single docker (private) image in the Digital Ocean container registry?

The permissions options on the API key are read or write for the whole project. There is basically no granularity.

It's not about the API key. It's about the container registry credentials. Which you would expect to be able to only interact with the container registry. This is not the case. If you go to the container registry and click to download credentials you will get JSON like:

    {"auths":{"registry.digitalocean.com":{"auth":""}}}
If you decode the base64 encoded credentials it will be a string like ":" with either a read only or read/write token to all of the resources on DO.

Re: In Digital Ocean, S3-like space keys can access all your buckets

#50

Post by fulafel »

sergioisidoro wrote: post #37
fulafel wrote: post #25

Click saver: this is about access keys, not bucket keys. (Which would have been in the original title...)

The point is that there are no bucket keys. Only Access keys for all buckets. There is no way to issue bucket specific keys. I'm not sure I follow how the title could be misleading.

We're still talking about different things: In S3, for an object known as s3://foo/bar, "bar" is the key. See eg https://docs.aws.amazon.com/AmazonS3/latest/userguide/object...

So the title is ambiguous, it could mean that keys have to be unique across buckets since they share the same namespace.

Post reply on HN