3 ms·

"Not through a web application vulnerability it can't (there is no application code to break!)." This isn't true. Data is being served up to web browsers over

by rsync 11y ago

"Not through a web application vulnerability it can't (there is no application code to break!)." This isn't true. Data is being served up to web browsers over port 80. That's a web server. It might not be like any web server you've ever run ... it might not be apache or thttpd or zeus or whatever ... but there is code that is spitting out HTTP over port 80/443. That's a web server. So let's say the S3 data is immutable, as far as the "web server" and the attacker are concerned ... that's very nice, of course, but if you have control over the web server, instead of parlaying that into control over the underlying data, just tell the web server to spit out other data. The S3 content is still safe and unchanged, but your website is nicely defaced, since your "amazon s3 webserver" exploit is just feeding it new content. (drastically oversimplified, of course - but be clear, if there is a web server (and there is) there is web-server-attack-surface)

dguido 11y ago
No one has the source or binary code for the webserver AWS uses. It would be nearly impossible to write an exploit for it blind like that. Even if you did write it blind, it would be a slow process that likely requires bruteforcing parts of the address space and there is no way you could do it without alerting Amazon. tl;dr what you described is possible, I guess, but so incredibly unlikely it's not even worth thinking about.
- morgante 11y ago
  Nobody has the source or binary code for dozens of proprietary systems which get hacked on a regular basis. In fact, I'd argue that most prominent hacks are of systems which are not open source.
  - ossreality 11y ago
    And are probably, for example, IIS which I can at least open in a debugger or hexedit and look at. Some very-proprietary service serving S3 content? Yeah, right.
- rsync 11y ago
  "tl;dr what you described is possible, I guess, but so incredibly unlikely it's not even worth thinking about." How would you rate it, in terms of "worth thinking about", relative to USB keys picked up off of the ground to infect industrial controllers to make centrifuges wiggle the wrong way ? Where would you stick that in, you know, in your "worth thinking about it" spectrum ? Just curious.
  - jmnicolas 11y ago
    I think it's not "worth thinking about" for someone that has to ask this question on HN.
- kriro 11y ago
  That is a very weak argument. If anything I'd argue it's a net negative and not a positive that the code is closed from a security POV.
- deleted 11y ago
  [deleted]
- c22 11y ago
  > No one has the source or binary code for the webserver AWS uses. Surely someone has access to this. Likely many many people. Do you know who they all are? Do you trust all of them to be neither malicious or careless.
ajross 11y ago
If the threat model posits an attacker with an exploit for Amazon S3, then we're well out of the realm that is appropriate for security questions about static web sites. That's not to say that S3 could not possibly be broken, but if it is, there are vastly more attractive targets for that attack than some random static site.
- rsync 11y ago
  "If the threat model posits an attacker with an exploit for Amazon S3" No, I'm not talking about an "S3 exploit". In fact, quite the opposite. I'm talking about an exploit for the web server that serves static S3 sites (and yes, it is a web server) which would serve arbitrary content instead of the underlying S3 content. The end user doesn't care that you injected the defaced content vs. altered the underlying content - defaced is defaced.
  - stevenae 11y ago
    In that situation, a malicious actor can execute arbitrary code on an S3 box that likely hosts all kinds of government / business critical data. OP's point is that unless your static website secretly contains nuclear launch codes, the actor will not spend his time coming after your site. You would hear about this kind of situation in the newspaper before your website would change.
geofft 11y ago
If Amazon is running a general-purpose web server with persistent state for S3 static hosting, I'd argue they're doing something very wrong. It's not hard to write a web server that reads from persistent storage but has no need or ability to write to persistent storage. (You can give it a cache, but the cache is destroyable.) So you can attack the web server in memory (maybe), but there's no way to persist the attack. As soon as the web server gets restarted, the attack goes away, and there's also no way to spread the attack from one web server to any of the countless others. Then it's a simple matter of load-balancing at scale and restarting these stateless web servers on a regular basis to make exploits infeasible, at least until you get to substantially more motivated and funded attackers. And Amazon is a fan of both load-balancing at scale and restarting things.

by rsync 11y ago

dguido 11y ago

No one has the source or binary code for the webserver AWS uses. It would be nearly impossible to write an exploit for it blind like that. Even if you did write it blind, it would be a slow process that likely requires bruteforcing parts of the address space and there is no way you could do it without alerting Amazon. tl;dr what you described is possible, I guess, but so incredibly unlikely it's not even worth thinking about.

morgante 11y ago
Nobody has the source or binary code for dozens of proprietary systems which get hacked on a regular basis. In fact, I'd argue that most prominent hacks are of systems which are not open source.
- ossreality 11y ago
  And are probably, for example, IIS which I can at least open in a debugger or hexedit and look at. Some very-proprietary service serving S3 content? Yeah, right.
rsync 11y ago
"tl;dr what you described is possible, I guess, but so incredibly unlikely it's not even worth thinking about." How would you rate it, in terms of "worth thinking about", relative to USB keys picked up off of the ground to infect industrial controllers to make centrifuges wiggle the wrong way ? Where would you stick that in, you know, in your "worth thinking about it" spectrum ? Just curious.
- jmnicolas 11y ago
  I think it's not "worth thinking about" for someone that has to ask this question on HN.
kriro 11y ago
That is a very weak argument. If anything I'd argue it's a net negative and not a positive that the code is closed from a security POV.
deleted 11y ago
[deleted]
c22 11y ago
> No one has the source or binary code for the webserver AWS uses. Surely someone has access to this. Likely many many people. Do you know who they all are? Do you trust all of them to be neither malicious or careless.

ajross 11y ago

If the threat model posits an attacker with an exploit for Amazon S3, then we're well out of the realm that is appropriate for security questions about static web sites. That's not to say that S3 could not possibly be broken, but if it is, there are vastly more attractive targets for that attack than some random static site.

rsync 11y ago
"If the threat model posits an attacker with an exploit for Amazon S3" No, I'm not talking about an "S3 exploit". In fact, quite the opposite. I'm talking about an exploit for the web server that serves static S3 sites (and yes, it is a web server) which would serve arbitrary content instead of the underlying S3 content. The end user doesn't care that you injected the defaced content vs. altered the underlying content - defaced is defaced.
- stevenae 11y ago
  In that situation, a malicious actor can execute arbitrary code on an S3 box that likely hosts all kinds of government / business critical data. OP's point is that unless your static website secretly contains nuclear launch codes, the actor will not spend his time coming after your site. You would hear about this kind of situation in the newspaper before your website would change.

geofft 11y ago

If Amazon is running a general-purpose web server with persistent state for S3 static hosting, I'd argue they're doing something very wrong. It's not hard to write a web server that reads from persistent storage but has no need or ability to write to persistent storage. (You can give it a cache, but the cache is destroyable.) So you can attack the web server in memory (maybe), but there's no way to persist the attack. As soon as the web server gets restarted, the attack goes away, and there's also no way to spread the attack from one web server to any of the countless others. Then it's a simple matter of load-balancing at scale and restarting these stateless web servers on a regular basis to make exploits infeasible, at least until you get to substantially more motivated and funded attackers. And Amazon is a fan of both load-balancing at scale and restarting things.