QEMU Advent Calendar: A surprise disk image each day until Christmas(qemu-advent-calendar.org)
qemu-advent-calendar.org
QEMU Advent Calendar: A surprise disk image each day until Christmas
https://qemu-advent-calendar.org/
8 comments
Today's image (netboot.xys) isn't even an image, it's just a shell script. It is both awesome and scary at the same time.
It boots an image straight from an unsecure http URL, and allows you to boot various BSDs and Linux flavours straight from the internet.
It boots an image straight from an unsecure http URL, and allows you to boot various BSDs and Linux flavours straight from the internet.
Hi, owner of https://netboot.xyz here. netboot.xyz has https support, with http support still being in place for those that don't have https support compiled into iPXE as it's not compiled by default. I'd recommend checking out the site directly if this is something that interests you. All of the source code running the site is on github as well and we're always open to contributions. We also always try to retrieve the installer kernels directly from the OS supported mirrors when possible so that they are pulled from trusted sources.
Hi, thanks for the work! I believe I first discovered netboot.xyz on a show HN. I have set up the DHCP in my lab to serve netboot.xyz, so I can experiment with different OS'es without much hassle. It has been great so far.
I even used it successfully on a VPS which had a limited about of OSes available. Awesome project!
netboot.xyz is great! My main use case is to boot things off of drac/ilo etc. If you have a remote server hosted in a datacenter and have struggled to use drac's virtual iso feature, boot the netboot iso. Since it's tiny, it works great for booting, and it switches to the primary NIC once the OS is booting. If you try to use your full iso with drac, it will be painfully slow because it goes through several layers of indirection (reverse proxies set up by your provider, the weird drac driver etc.)
Do you serve the main images over tftp and is it reliable? We have been building an NBD server with this use case in mind and had on and off discussions with Foreman people about a similar case. In theory NBD should be much more efficient since it will only serve the main image on demand (but if you want you can still use it like tftp by copying /dev/nbd0 to a ram disk at boot). It also supports TLS.
https://github.com/libguestfs/nbdkit
https://github.com/libguestfs/nbdkit/blob/master/plugins/flo...
https://github.com/libguestfs/nbdkit
https://github.com/libguestfs/nbdkit/blob/master/plugins/flo...
most tftpd (note: not ftpd or sftpd) were really not intended to be exposed to the traffic of a public internet connection. They're for stuff like serving an image to a voip phone that is booting on a LAN with tftp parameters to go and get a .xml provisioning file.
Does this mean I can use this to boot ISOs off my home server? That would be great for installing Ubuntu, for example. Is there a guide on how to do this somewhere?
I wish something like that existed for various single-board computers that are getting popular nowadays. Any sort of flexibility would be welcome, writing big images on a SD card gets old very fast. Yes, many things probably won't boot, but I'd rather find out that they don't quickly.
The latest rPi can do PXE (ethernet boot) over wired ethernet (no support for PXE over WiFi yet).
I have set this up and it is pretty cool to quickly boot images over the network this way, and experiment with them without having to write SD cards. In fact: my rPI doesn't even have a SD card inserted.
The ethernet performance in the RPI is still poor though, the USB-to-ethernet bridge is suboptimal.
I guess we're almost back at running RPi 'terminals' on our desktop and have a centralised (cloud?) storage solution to boot from and persist files to. We're almost back at 90's level computing ;-)
I have set this up and it is pretty cool to quickly boot images over the network this way, and experiment with them without having to write SD cards. In fact: my rPI doesn't even have a SD card inserted.
The ethernet performance in the RPI is still poor though, the USB-to-ethernet bridge is suboptimal.
I guess we're almost back at running RPi 'terminals' on our desktop and have a centralised (cloud?) storage solution to boot from and persist files to. We're almost back at 90's level computing ;-)
I don't know about other ones, but you can netboot the Raspberry Pi 3: https://www.raspberrypi.org/documentation/hardware/raspberry...
I use an APU, but with any netboot small computer, I find it easier to netboot a simple linux build and dd the image via netcat, vs plugging and unplugging the card.
My notes for pfsense: receiving machine: netcat -l 2222 | gzip -dc | dd of=/dev/sda
sending machine: dd if=pfSense-2.2.4-RELEASE-2g-i386-nanobsd.img.gz |netcat 10.10.10.101 2222
My notes for pfsense: receiving machine: netcat -l 2222 | gzip -dc | dd of=/dev/sda
sending machine: dd if=pfSense-2.2.4-RELEASE-2g-i386-nanobsd.img.gz |netcat 10.10.10.101 2222
replace dd with shell redirection or cat...
[deleted]
Is there significant risk in booting untrusted OS images within Qemu?
You need to take steps to harden qemu - I wouldn't do it with qemu out of the box using the command line. In RHEL (eg for Red Hat's OpenStack) we do:
* Aggressively compile out unused features/devices.
* Confine each VM with separate SELinux contexts (sVirt).
* Run qemu as a special non-root user.
* Use seccomp to confine the system calls.
* Pass in pre-opened file descriptors to qemu, so qemu doesn't need to open files (helps with writing tightly confined SELinux policy).
* Run qemu in a cgroup.
* Run qemu-img with resource limits.
* Compile qemu with all hardening features enabled like RELRO, PIE, etc.
* Audit the code manually and with Coverity.
* Take security reports seriously and have a fast patching mechanism (you can effectively "live patch" qemu by migrating a VM off the old qemu and on to the new qemu).
Probably more that I've forgotten about ...
* Aggressively compile out unused features/devices.
* Confine each VM with separate SELinux contexts (sVirt).
* Run qemu as a special non-root user.
* Use seccomp to confine the system calls.
* Pass in pre-opened file descriptors to qemu, so qemu doesn't need to open files (helps with writing tightly confined SELinux policy).
* Run qemu in a cgroup.
* Run qemu-img with resource limits.
* Compile qemu with all hardening features enabled like RELRO, PIE, etc.
* Audit the code manually and with Coverity.
* Take security reports seriously and have a fast patching mechanism (you can effectively "live patch" qemu by migrating a VM off the old qemu and on to the new qemu).
Probably more that I've forgotten about ...
Please make a gist or blog post!
This sounds like a lot of fun. What are you doing with those VMs?
I work for Red Hat and this is how VMs are configured by default if you buy RHV, RHOSP, KubeVirt or similar on-prem or public virtualization or cloud products from us. You can turn some of these mitigations off if you want, although I wouldn't personally recommend it - at some time of another there has been a security critical bug which has been mitigated by each one of these changes.
Some of our customers are running untrusted VMs in their public clouds using this configuration. Others will be running on-premises virtualization set ups with VMs from across their companies which can be equally risky.
SELinux is probably the most important mitigation in the list, and while it has a bad reputation that's mostly from people who haven't used it for over a decade. I have SELinux enforcing on every machine I use, and it rarely causes an issue.
Some of our customers are running untrusted VMs in their public clouds using this configuration. Others will be running on-premises virtualization set ups with VMs from across their companies which can be equally risky.
SELinux is probably the most important mitigation in the list, and while it has a bad reputation that's mostly from people who haven't used it for over a decade. I have SELinux enforcing on every machine I use, and it rarely causes an issue.
Short Answer: Yes.
Historic(2015) VM escape example https://venom.crowdstrike.com/
I doubt anyone is wasting a good zero-day on disposable qemu netboot images. Someone may try a venom(like) image for 'fun'.
Historic(2015) VM escape example https://venom.crowdstrike.com/
I doubt anyone is wasting a good zero-day on disposable qemu netboot images. Someone may try a venom(like) image for 'fun'.
It is unknown. It might be unknowable.
Due to a couple downvotes I want to explain by way of a question: Can it to your knowledge be proven that QEMU is fully secure?
Given that bugs which have been found in it previously have been fixed, can we know from now on that it’s 100% safe?
As far as I know there does not exist a way of rigorously proving that.
fwiw my interest in theoretical computers and formal verification based on this fundamental aspect.
Given that bugs which have been found in it previously have been fixed, can we know from now on that it’s 100% safe?
As far as I know there does not exist a way of rigorously proving that.
fwiw my interest in theoretical computers and formal verification based on this fundamental aspect.
Specifically, for those wondering
http://boot.netboot.xyz
which in turn does
http[s]://boot.netboot.xyz/menu.ipxe
http://boot.netboot.xyz
which in turn does
http[s]://boot.netboot.xyz/menu.ipxe
I don't understand the complaints about this. What does https buy you in this case ?
Security against your client-server communications' contents being observed by third parties. So here https ... gives ... confidentiality ... to ... public ... images. Well that's useful !
It does not prevent server spoofing attacks (as in attackers changing the code you boot) in 99% of situations. Nor man-in-the-middle protection ...
So what's the point of https in this situation ? Certificate, cert pinning, ... are all useless in this situation (certificate only helps on repeat visits, which of course never applies in this situation. Cert pinning only helps for specific sites (not this one) and even if it did, only when the originating software is really up to date (which is just not going to be the case here).
So you can just as well say that http is perfectly secure in this case. Or at least ... as secure as https is going to be.
There's quite a bit more to security than "use https".
Security against your client-server communications' contents being observed by third parties. So here https ... gives ... confidentiality ... to ... public ... images. Well that's useful !
It does not prevent server spoofing attacks (as in attackers changing the code you boot) in 99% of situations. Nor man-in-the-middle protection ...
So what's the point of https in this situation ? Certificate, cert pinning, ... are all useless in this situation (certificate only helps on repeat visits, which of course never applies in this situation. Cert pinning only helps for specific sites (not this one) and even if it did, only when the originating software is really up to date (which is just not going to be the case here).
So you can just as well say that http is perfectly secure in this case. Or at least ... as secure as https is going to be.
There's quite a bit more to security than "use https".
> What does https buy you in this case ?
It ensures the response from the webserver really is from netboot.xyz, and not from any mitm server.
> It does not prevent server spoofing attacks (as in attackers changing the code you boot) in 99% of situations. Nor man-in-the-middle protection ...
Can you elaborate? How would you spoof the server response without having a valid certificate key for the netboot.xyz domain?
It ensures the response from the webserver really is from netboot.xyz, and not from any mitm server.
> It does not prevent server spoofing attacks (as in attackers changing the code you boot) in 99% of situations. Nor man-in-the-middle protection ...
Can you elaborate? How would you spoof the server response without having a valid certificate key for the netboot.xyz domain?
For this to work trusted CAs need to be compiled into the iPXE binary. Since those can change you'll need to update that binary from time to time. Or ignore cert warnings, which reduces the security to plain HTTP.
>> server spoofing attacks (as in attackers changing the code you boot)
> Can you elaborate?
I think this is referring to the server being compromised. This isn't something that can be solved easily because while the bootloader could include signify[1] to verify its downloads, the bootloader itself can't be verified with anything. (disclaimer: I don't know very much about iPXE)
https://www.openbsd.org/papers/bsdcan-signify.html
I think this is referring to the server being compromised. This isn't something that can be solved easily because while the bootloader could include signify[1] to verify its downloads, the bootloader itself can't be verified with anything. (disclaimer: I don't know very much about iPXE)
https://www.openbsd.org/papers/bsdcan-signify.html
Assuming they're performing proper CA verification it lowers the trust level from your entire connection to just the CAs and netboot.xyz administrators - preventing MITM attacks in the local network where they're most often performed. Perhaps it's not perfect but it seems like a pretty major improvement.
I always assumed people who use netboot are running a distribution mirror inside their "data center".
The source for F-Bird the boot sector game (day 1) is here: https://github.com/nanochess/fbird and it's an incredible bit of engineering. 3 unused bytes too :-)
This year also marks the 15th anniversary of QEMU.
netboot.xyz is such an awesome project. I added it to most of my USB boot disks as a grub entry (on my SystemRescueCD USB thumbdrive, etc), so I'm almost never stuck when I need to deploy an OS on the go.
There are still a couple of open slots, so feel free to send ideas (or even better -- prepared images) to the contact e-mail address mentioned on the website.
Hoping for some cool non-x86 and non-Linux systems.
It features disk images of interest to hackers or to show off features from the many emulated hardware platforms that QEMU supports.
Happy holidays! And if you have a bootable image you'd like to contribute, check out the calendar website to get in touch.