15 Dec
2016
15 Dec
'16
9:49 a.m.
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:
…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:
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