Live data from Hacker News

AWS issues unavoidable reboot schedules with short notice on many EC2 instances

forums.aws.amazon.com

11–20 of 160 posts

Re: AWS issues unavoidable reboot schedules with short notice on many EC2 instances

#12
post #10
post #8

Earlier quoted context omitted.

It seems like providing a script that identifies if your system is vulnerable to an embargoed XSA would be a violation of the predisclosure list, since it would basically be pointing at what the issue was?

How does one bit of information (vulnerable / not vulnerable) tell you what the vulnerability is?

It's not the results of the script that I'm referring to, it's the contents of the script. If I hand you code that can look at your system and determine something about it, you can look at what the code is doing and identify what it is looking at, which tells you where the vulnerability is.

It becomes moderately harder if it's compiled code, but still not very difficult.

Re: AWS issues unavoidable reboot schedules with short notice on many EC2 instances

#13
EC2 screenshot: http://i.imgur.com/OdCehey.png

And copy of the email that was sent out to us...

----

Dear Amazon EC2 Customer,

One or more of your Amazon EC2 instances are scheduled to be rebooted for required host maintenance. The maintenance will occur sometime during the window provided for each instance. Each instance will experience a clean reboot and will be unavailable while the updates are applied to the underlying host. This generally takes no more than a few minutes to complete.

Each instance will return to normal operation after the reboot, and all instance configuration and data will be retained. If you have startup procedures that aren’t automated during your instance boot process, please remember that you will need to log in and run them. We will need to do this maintenance update in the window provided. You will not be able to stop/start or re-launch instances in order to avoid this maintenance update.

If you are using Windows Server 2012 R2, please follow the instructions found here: http://aws.amazon.com/windows/2012r2-network-drivers/ to ensure that your instance continues to have network connectivity after reboot. This requires that you run a remediation script in order to ensure continued access to your instance.

Additional information about Amazon EC2 maintenance can be found at: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/mo...

If you have any questions or concerns, you can contact the AWS Support Team on the community forums and via AWS Premium Support at: http://aws.amazon.com/support.

Sincerely,

Amazon Web Services

To view your instances that are scheduled for reboot, please visit the 'Events' page on the EC2 console: https://console.aws.amazon.com/ec2

This message was produced and distributed by Amazon Web Services LLC, 410 Terry Avenue North, Seattle, Washington 98109-5210.

Re: AWS issues unavoidable reboot schedules with short notice on many EC2 instances

#14
post #7

They say that its fine to reboot but that there is no guarantee that you will land on an updated host. However, AWS does provide a script to run on Windows machines which should tell you if that particular machine has the issue. I took a quick look at the script and deduced that it is indeed a Xen issue.

This is not related to the scheduled reboot maintenance. The script that you are referring to has to do with a separate Windows networking driver and Xen.

Re: AWS issues unavoidable reboot schedules with short notice on many EC2 instances

#15
post #7

They say that its fine to reboot but that there is no guarantee that you will land on an updated host. However, AWS does provide a script to run on Windows machines which should tell you if that particular machine has the issue. I took a quick look at the script and deduced that it is indeed a Xen issue.

Post the script?

It seems they could easily hit the metadata service to determine if a machine is patched or not.

Re: AWS issues unavoidable reboot schedules with short notice on many EC2 instances

#16
post #12
post #10

Earlier quoted context omitted.

How does one bit of information (vulnerable / not vulnerable) tell you what the vulnerability is?

It's not the results of the script that I'm referring to, it's the contents of the script. If I hand you code that can look at your system and determine something about it, you can look at what the code is doing and identify what it is looking at, which tells you where the vulnerability is. It becomes moderately harder if it's compiled code, but still not very difficult.

Unless the fixed version of Xen exposes some kind of signal to its VMs that says "Hi, I'm not affected!" - which then could be read by this script. I don't know if and how that's possible with Xen though.

Re: AWS issues unavoidable reboot schedules with short notice on many EC2 instances

#18
post #12
post #10

Earlier quoted context omitted.

How does one bit of information (vulnerable / not vulnerable) tell you what the vulnerability is?

It's not the results of the script that I'm referring to, it's the contents of the script. If I hand you code that can look at your system and determine something about it, you can look at what the code is doing and identify what it is looking at, which tells you where the vulnerability is. It becomes moderately harder if it's compiled code, but still not very difficult.

So make the code query an opaque EC2 api, instead of testing the machine. You could still find a machine that is vulnerable and one that isn't and attempt to find out what the difference is, but that's a much harder task.

Re: AWS issues unavoidable reboot schedules with short notice on many EC2 instances

#20
post #8
post #7

They say that its fine to reboot but that there is no guarantee that you will land on an updated host. However, AWS does provide a script to run on Windows machines which should tell you if that particular machine has the issue. I took a quick look at the script and deduced that it is indeed a Xen issue.

It seems like providing a script that identifies if your system is vulnerable to an embargoed XSA would be a violation of the predisclosure list, since it would basically be pointing at what the issue was?

maybe just checking a version number or a compilation date? Indirect check?
Post reply on HN