My 5p is very much in line with the list consensus so far.
Any issue that concerns memory or disk access outside of bounds is a
very good reason for patching ASAP.
And it is not like it is you fault Andy. To me, the fact you do patch
the servers as soon as possible says to me that Bitfolk takes security
seriously. So it is not an inconvenience as far as I am concerned,
rather a reason to trust and recommend Bitfolk.
If anyone needed better availability than what Bitfolk has to offer,
they should be prepared to pay quite a bit more. Bitfolk is not a
HA-service provider. Even if it almost feels like that some times! ;-)
Have been using Bitfolk for quite some time now and I am very pleased
as a customer with the availability and service. A lot of other
providers offers worse service for a lot of more money.
Thanks,
__
/ony
-------
Wednesday, December 14, 2016, 12:41:52 PM, Andy wrote:
> On Tue, Dec 13, 2016 at 03:17:53AM +0000, Andy Smith wrote:
>> Hi,
>>
>> On Wed, Nov 30, 2016 at 06:00:35AM +0000, Andy Smith wrote:
>> > Rather disappointingly there's been another round of security
>> > advisories for Xen, some of which affect the configuration in use at
>> > BitFolk:
>>
>> The maintenance work to patch against this bug (XSA-200) has now
>> been completed, without incident.
> Now that this is out of embargo:
> http://xenbits.xen.org/xsa/advisory-200.html
> …perhaps I could have a bit of feedback from you as to whether we
> did the right thing in enforcing a reboot here.
> Discussion around the bug (unfortunately on a private list for
> discussion of the security bugs while they're under embargo, so I
> can't show you) indicated that it *probably* wasn't very dangerous.
> The impact is basically that a guest VM could read either 32 or 96
> bits of hypervisor memory. It would probably be a different 96 bits
> each time, but probably not anything private.
> Of course, the Xen folks are not being paid to speculate on exactly
> how exploitable that bug is, so they can't be drawn into making any
> statements about how likely it is that any sensitive data could be
> read. Their official analysis quite reasonably stops at "guests can
> read some hypervisor memory; here is the patch for that".
> As the matter was under embargo it was difficult to discuss any
> further than that, hence all I've got is "it probably isn't that
> serious". That was based on some insights that it seems similar to
> an earlier bug that also probably wasn't as serious as its
> corresponding advisory implied - bearing in mind that an advisory
> should tell you the worst case. Analysis of a similar bug:
>
> https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-012-2014.txt
> That one involved the ability to read a couple of kB of hypervisor
> memory, whereas XSA-200 was limited to 96 bits. So XSA-200 is almost
> likely less serious than XSA-108 was.
> So, did we do the right thing in patching and rebooting this before
> the embargo date (leading to less than 2 weeks of notice of a reboot
> for customers)?
> Should we have patched and rebooted but over a longer schedule?
> Should we have not bothered with a reboot at all?
> Cheers,
> Andy
