Live data from Hacker News

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

ideas.digitalocean.com

51–60 of 104 posts

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

#51
post #9
post #7

Earlier quoted context omitted.

Could you provide more details?

On delete of VMs, the next user to be allocated disk would be able to read your data. There was a "scrub" feature that would bill you longer/extra to zeroize your data and not give it to the next customer. Apparently they hadn't heard of TRIM or thin provisioning. https://github.com/fog/fog/issues/2525 https://news.ycombinator.com/item?id=6983097 https://news.ycombinator.com/item?id=6983520

I actually came here to add this very issue and then noticed this comment.

This issue is the reason why I will never use DO or recommend it to a customer.

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

#52
post #42
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…

Imagine if your bank told you they only close the vault when a customer asks.

And they give you an excuse that it’s time consuming for them and you should respect their time.

Would you bank with them?

This is a pathetic response and you are dragging your former company through the mud by putting the incompetence that you participated in, front and center.

It’s amazing that this happened so long ago and yet you seemed to have learned nothing from it, and now want to double down on your right to leak sensitive data (because it was convenient at the time)

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

#53
post #35
post #11

Earlier quoted context omitted.

No such luck there, but this is kind of the MO for DigitalOcean, sadly.

I think DO is doing fine addressing their target market. I also wish they had IAM but you have to admit IAM is huge and messy and is often more about managing your employees than your infrastructure. I’m okay waiting for them to get it right rather than rushing out a quick half baked idea that ruins their entire product stack err platform.

I don't care for the full on flexibility of IAM, but I'd kill for a simple "this key is for this bucket" feature. That doesn't seem so far fetched, I don't need per-object permissions within a single bucket!

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

#54
I don't know if they've improved it, but 5 years ago I basically couldn't delete a DO Space because they had no way of doing a mass deletion. I even got technical support who basically told me I was doing it the best way possible. My delete operation took several months to run.

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

#55
post #28
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…

> there isn't actually a security issue, the fog app wasn't passing the scrub flag

At a certain point a default behaviour can be so bad, and so clearly not what a user would expect or want, that it constitutes a security issue. I would think this _more_ than qualifies.

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

#56
post #52
post #42

Earlier quoted context omitted.

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…

Imagine if your bank told you they only close the vault when a customer asks. And they give you an excuse that it’s time consuming for them and you should respect their time. Would you bank with them? This is a pathetic response and you are dragging your former company through the mud by putting the incompetence that you participated in, front and center. It’s amazing that this happened so long ago and yet you seemed…

I was always very clear at that time "this is a startup" - "do not use DO for mission critical work" - "the product is not very mature yet" - we had no sales team, nothing in our marketing was gear towards business and we primarily catered to students/personal sites/etc. I'd accept your analogy except we regularly said "use AWS for important stuff, not us".

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

#57
post #42
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…

> tried (sic) up a lot of resources on the box

Do you know what else ties up a lot of resources? Civil action, negligence claims, PR disasters.

This specific GitHub issue is one of several why I will never use DO: language, official response, and attitude all matter. I'd be curious to know how much revenue DO has lost because of this one issue.

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

#58

And DO consistently ignores requests to add this. It prevents me from seriously using Spaces and I think many others, too.

See also this old comment on security issues with their managed Kubernetes offering.

https://news.ycombinator.com/item?id=22490390

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

#59
post #54

I don't know if they've improved it, but 5 years ago I basically couldn't delete a DO Space because they had no way of doing a mass deletion. I even got technical support who basically told me I was doing it the best way possible. My delete operation took several months to run.

That is a limitation that comes along with having to be S3 compatible; the best you can do is to combine ListObjectsV2[1] + DeleteObjects[2] (1000 objects in a single API call).

[1] https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObje...

[2] https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteOb...

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

#60
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…

> there isn't actually a security issue, the fog app wasn't passing the scrub flag At a certain point a default behaviour can be so bad, and so clearly not what a user would expect or want, that it constitutes a security issue. I would think this _more_ than qualifies.

You're right. I hadn't really thought about it that way. My response at the time actually came from confusion on my part (that is my own fault I suppose). I got woken up at 4am on a Sunday by a flood of calls saying there is a post on the top of HN about DO leaking data between VMs. I got out of bed to see if I needed to wake up the engineering team, checked the support system and the disclosure emails because my first thought was shit someone has pwned the LXC/escaped the jails or something. Then when I read the github, I thought the scrub flag wasn't being respected when it was passed. That was the type of security issue I had originally taken it to mean, both I would have woken up engineering for. It was a someone is in the hypervisor type of security issue I thought we were dealing with. Once I realized it was fog didn't pass the scrub flag, I wish I'd just gone back to bed and dealt with it on Monday instead of trying to do it in real time, that was stupid of me. I also accept your point that an unexpected behaviour can in itself be a security issue.
Post reply on HN