71–80 of 124 posts
Amazon states that AWS is not vulnerable, no details but presumably they patched before the public disclosure. https://aws.amazon.com/security/security-bulletins/XSA_Secur...
Code reuse is great, unless it is Qemu?
If there's a solution to this problem, I don't know what it is. Trying to replace an underfunded monoculture with severely underfunded diverse implementations may not even work and may actually reduce security.
Given the complexity of QEMU and its pace of development, there is likely an endless supply of such bugs for punching through the QEMU emulation layer. The problem is that most of the time, the QEMU process is running in dom0, giving an attacker an opportunity to hijack the hypervisor. Xen offers a more general solution for this: running QEMU in a stub domain. The main problem with that solution right now is that Xen…
I don't like this trend of "marketing vulnerabilities" with a cute name and a startup-looking landing page. That entire page says nothing about the actual issue, the nice looking graphic just shows how this exploit (and really any exploit like this?) can give attackers access to things outside of a VM. Duh.
Why don't you like this trend? I don't see the harm. Also, the FAQ explains a lot; including the details of how the vulnerability works.
The added design here seems a waste of effort and not really adapted to the targeted audience.
EDIT: The xen advisory gives you all the info you need in a couple of block of text: http://xenbits.xen.org/xsa/advisory-133.html
A simpler, less breathless description from the Red Hat BZ[1] An out-of-bounds memory access flaw was found in the way QEMU's virtual Floppy Disk Controller (FDC) handled FIFO buffer access while processing certain FDC commands. A privileged guest user could use this flaw to crash the guest or, potentially, execute arbitrary code on the host with the privileges of the hosting QEMU process. If you're using RHEL, then…
So, what you're saying is you don't expect attackers who can write exploits to escape a VM to be able to write a linux privilege escalation exploit when SELinux is enabled?
Earlier quoted context omitted.
How is it bad that large providers have an opportunity to patch before the vulnerability is released to the wild? Maybe next you'll insist that everyone's prevented from patching for a week after disclosure so that smaller companies that don't have the resources to react immediately are not unfairly left behind?
I'm not insisting anything. I'm just saying that lack of immediate and full disclosure is essentially crony capitalism where there are the Big Important Companies That Must Be Protected and then there is everybody else, including small startups and private individuals. It is fundamentally unfair, and sets up a non-level playing field. (inb4 "critical infrastructure")
It is fundamentally unfair, and is perfectly reasonable.
I don't like this trend of "marketing vulnerabilities" with a cute name and a startup-looking landing page. That entire page says nothing about the actual issue, the nice looking graphic just shows how this exploit (and really any exploit like this?) can give attackers access to things outside of a VM. Duh.