TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

EC2's most dangerous feature

256 点作者 dwaxe超过 8 年前

19 条评论

hueving超过 8 年前
The blog post buries the lead a little bit because it&#x27;s talking about lots of pain points with the ec2 API and IAM. The important point to take away is that any process with network access running on your instance can contact the EC2 metadata service at <a href="http:&#x2F;&#x2F;169.254.169.254" rel="nofollow">http:&#x2F;&#x2F;169.254.169.254</a> and get the instance-specific IAM credentials.<p>Think about things like services that accept user submitted URLs, crawl them, and display results...
评论 #12673260 未加载
评论 #12673033 未加载
评论 #12672284 未加载
评论 #12672225 未加载
评论 #12672153 未加载
评论 #12672226 未加载
cesarb超过 8 年前
What I&#x27;ve done for a previous company was to, as one of the very first things done within every EC2 instance, add an iptables owner match rule to only allow packets destined to 169.254.169.254 if they come from uid 0. Any information from that webservice that non-root users might need (for instance, the EC2 instance ID) is fetched on boot by a script running as root and left somewhere in the filesystem.
评论 #12671028 未加载
评论 #12671058 未加载
评论 #12671043 未加载
skywhopper超过 8 年前
Hopefully the operators using EC2 instance profiles understand and weigh the risks of using that feature. It&#x27;s good to be cautious, but the feature is only dangerous if you don&#x27;t take the time to understand it. Running a server on the Internet at all is &quot;dangerous&quot; in the same sense. And for this particular risk, it turns out there&#x27;s a simple fix.<p>He _is_ right in his first criticism that the IAM access controls available for much of the AWS API are entirely inadequate. In the case of EC2 in particular, it&#x27;s all or nothing--either your credentials can call the TerminateInstances API or they can&#x27;t. I&#x27;m sure Amazon is working on improving things, but for now it&#x27;s pretty terrible. But in practice it just means you have to take care in different ways than you would if his tag-based authz solution were implemented.<p>That said, while it&#x27;s certainly frustrating to an implementor, it&#x27;s not &quot;dangerous&quot; that limitations exist in these APIs. We&#x27;re talking about decade-old APIs from the earliest days of AWS, and while things have been added, the core APIs are still the same. That&#x27;s an amazing success story. But like any piece of software, there are issues that experienced users learn how to work around.<p>You can bet that the EC2 API code is hard and scary to deal with for its maintainers. Adding a huge new permissions scheme is likely nearly impossible without a total rewrite... I don&#x27;t envy them their task.
评论 #12671334 未加载
评论 #12678039 未加载
评论 #12673261 未加载
_hyn3超过 8 年前
tl;dr:<p>1) IAM instance roles have <i>no</i> security mechanisms to protect them from being read from any process on the instance, thus completely eliminating them from all Linux&#x2F;UNIX&#x2F;Windows permission systems. (The real reason for this is that instance metadata was a convenient semi-public information store for things like instance ID, but it was extended to also provide secret material, which was, at best, an idiotic move.) As the author points out, Xen already provided a great filesystem alternative that could be mounted as another drive (or network drive) to be managed with the regular OS filesystem permission system. (reading an instance ID is just a matter of reading a &quot;file&quot;)... for some reason, AWS didn&#x27;t leverage this and instead just added the secret material to its local instance metadata webserver.<p>2) the API calls are not fine grained enough and&#x2F;or there are big holes in their coverage -- so, for instance, if you want to use some other AWS services, you can end up exposing much more than you intended.
0x0超过 8 年前
This is interesting! Can this be abused with AWS-hosted services that reach out to fetch URLs? For example, image hosts that allow specifying an URL to retrieve, or OAuth callbacks, etc? Are there any tricks to be played if someone were to register a random domain and point it to 169.254.169.254 (or worse, flux between 169.254.169.254 and a public IP in case there is blacklisting application code that first checks to resolve the hostname but then passes the whole URL into a library that resolves again?)
评论 #12670992 未加载
评论 #12670642 未加载
评论 #12670753 未加载
评论 #12672814 未加载
gtsteve超过 8 年前
This is an interesting attack that I must confess I hadn&#x27;t thought of, but surely any service that accepts an arbitrary URL has a list of IP ranges to avoid. However, to harden a role in the event of instance role credentials leaking, you could use an IAM Condition [0].<p>There is actually an example of this in the IAM documentation [1], although the source VPC parameter doesn&#x27;t work for all services, and I can&#x27;t see a list of services that support this parameter. This would ensure that the requests actually came from instances within your VPC.<p>[0] <a href="http:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;IAM&#x2F;latest&#x2F;UserGuide&#x2F;reference_policies_elements.html#Condition" rel="nofollow">http:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;IAM&#x2F;latest&#x2F;UserGuide&#x2F;reference_po...</a><p>[1] <a href="http:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;AmazonS3&#x2F;latest&#x2F;dev&#x2F;example-bucket-policies-vpc-endpoint.html#example-bucket-policies-restrict-access-vpc" rel="nofollow">http:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;AmazonS3&#x2F;latest&#x2F;dev&#x2F;example-bucke...</a>
评论 #12671361 未加载
评论 #12672507 未加载
rcaught超过 8 年前
&gt; almost as trivial for EC2 instances to expose XenStore as a filesystem to which standard UNIX permissions could be applied, providing IAM Role credentials with the full range of access control functionality which UNIX affords to files stored on disk.<p>Doesn&#x27;t this become more complicated when you think about EC2 offering Windows instances? Even with straight UNIX file writing, what writes this? Where does it write this? Which user has read permissions?
评论 #12671351 未加载
评论 #12671217 未加载
Rapzid超过 8 年前
I&#x27;ve used firewall rules in the past to scope the metadata store to admin users.
评论 #12670541 未加载
patsplat超过 8 年前
EC2 instances are designed to enforce isolation between instances, not processes. Presumably there would only be one primary service running on each.<p>Use AWS be pushed towards an architecture based on containers and services. AWS is the OS, not any individual machine.
jamiesonbecker超过 8 年前
Until AWS fixes this (which, as the article points out, may never happen), a chmod&#x27;ed 600 file (only readable by root) is actually much safer, even when STS auto-rotation is taken into account.
djb_hackernews超过 8 年前
If users can issue arbitrary commands on an instance then that instance should have zero Iam roles and should delegate actions to services running on separate instances.<p>The instances hosting our users go a step further and null route Metadata service requests via iptables.
评论 #12671047 未加载
tex0超过 8 年前
It&#x27;s much like the same Problem with the Google Cloud. Even worse there I&#x27;d say.
评论 #12670745 未加载
评论 #12672230 未加载
yandie超过 8 年前
If you&#x27;re sharing the same instance for multiple users, trying to achieve security among the users is almost impossible anyway. That&#x27;s why physical separation&#x2F;virtualization is one of the first thing to focus on when talking about security.
评论 #12671514 未加载
icedchai超过 8 年前
IAM instance roles are still an improvement over how it was typically done in the past: hard-coding the same key in a configuration file and deploying it everywhere.<p>It&#x27;s a balance between security and convenience.
zimbatm超过 8 年前
I wonder how many services on Amazon allow user-configurable webhooks that can be pointed to <a href="http:&#x2F;&#x2F;169.254.169.254" rel="nofollow">http:&#x2F;&#x2F;169.254.169.254</a> ...
logronoide超过 8 年前
Same happens with metadata access in Openstack.<p>The access is controlled by source IP (and namespace). I wonder if it&#x27;s possible to spoof the IP and access Metadata of other servers&#x2F;users.
Thaxll超过 8 年前
It has been the case for 10 years, anyone knows that, I don&#x27;t see the problem. If you&#x27;re not happy with it just use API keys.
评论 #12673441 未加载
cperciva超过 8 年前
OK, dwaxe, I have to ask: Are you a robot? Because I uploaded this blog post, tweeted it, and then came straight over here to submit it and you <i>still</i> got here first.<p>Not that I mind, but getting your HN submission in within 30 seconds of my blog post going up is very impressive if you&#x27;re <i>not</i> a robot.
评论 #12676154 未加载
评论 #12670511 未加载
评论 #12670766 未加载
评论 #12670459 未加载
评论 #12671151 未加载
评论 #12670386 未加载
评论 #12671041 未加载
评论 #12670683 未加载
评论 #12670428 未加载
ChoHag超过 8 年前
The number of people in this thread not merely nodding their heads and mmhmm-ing (or the internet equivalent) is a concern.