[GH-ISSUE #167] boot.netboot.xyz initial loader #1613

New issue

Closed

opened 2026-03-01 18:34:50 +03:00 by kerem · 1 comment

kerem commented

2026-03-01 18:34:50 +03:00

Owner

Originally created by @ehuggett on GitHub (Aug 1, 2017).
Original GitHub issue: https://github.com/netbootxyz/netboot.xyz/issues/167

Hi,

I have some feedback i would like to share but first i would like to say, Great work! Thanks for sharing a very interesting/useful project.

[This is all untested speculation. I believe i have a good grasp all the relevant concepts, but i am not overly familiar with iPXE or netboot.xyz. Please accept my sincere apologies in advance if any claims/statements i make here are incorrect.]

It looks like 8a8ba58c00 made https(s)://boot.netboot.xyz(/index.html) compatible with iPXE clients that do not support https (or perhaps just cannot verify the certificate for it?).

While i think its great that http connections are upgraded to https if possible, I think it would be better if there was no fallback to http if the client made the initial request over https due to the following

Assuming an attacker is in a position to intercept, inspect and modify network traffic between the iPXE client and the http server:

If iPXE makes a new connection to boot.netboot.xyz to retrieve menu.ipxe (or if this file was stored on a different domain from the initial loader in the future) then allowing the first secure connection (index.html) but blocking the second (menu.ipxe) will cause the client to fallback to http, which could then be hijacked (redirected to the attackers own http server) allowing them to provide a config which will (automatically without user interaction?) execute a malicious payload.
If iPXE is able to reuse the existing secure connection to boot.netboot.xyz it might still be possible to achieve point 1 if the attacker interrupts (by dropping packets or injecting TCP resets) the secure connection AFTER index.html has been retrieved but BEFORE menu.ipxe has been. Despite it being a secure connection, the attacker can still observe the amount of data being transferred and index.html is of a known size so i think this could be plausible.

Suggestions (not in any particular order) that would address this concern

Is it possible to provide a combined config where the http fallback will be ignored by clients which loaded it over https?
Serve different initial loaders depending upon which protocol the request was made over (might complicate the webserver config)
Use a completely different domain or url for people who know their client cannot retrieve the initial loader securely, but for some reason they wish to do it anyway.
The least practical, but my favourite nonetheless... Encrypt the web! Simply drop support for http (and don't redirect from http to https either, if anyone gets in the habit of using it then the connection could be hijacked the next time they do as unlike a browser iPXE can't store received HSTS policies for use "next time" they boot it).

N.B. Just to put it in perspective for anyone overly concerned about the above, if the attacker is on your local network and DHCP filtering (etc) is not enabled on your switches they could simply respond to your computer's DHCP request before the legitimate DHCP server does and execute any payload they wish without netboot.xyz being involved in any way whatsoever. As useful as it can be, Think about this before blindly enabling PXE as a default boot option (certainly before making it THE default boot option).

Originally created by @ehuggett on GitHub (Aug 1, 2017). Original GitHub issue: https://github.com/netbootxyz/netboot.xyz/issues/167 Hi, I have some feedback i would like to share but first i would like to say, Great work! Thanks for sharing a very interesting/useful project. [This is all untested speculation. I believe i have a good grasp all the relevant concepts, but i am not overly familiar with iPXE or netboot.xyz. Please accept my sincere apologies in advance if any claims/statements i make here are incorrect.] It looks like 8a8ba58c00855df883540e89ce6999266a572b5e made https(s)://boot.netboot.xyz(/index.html) compatible with iPXE clients that do not support https (or perhaps just cannot verify the certificate for it?). While i think its great that http connections are upgraded to https if possible, I think it would be better if there was no fallback to http if the client made the initial request over https due to the following Assuming an attacker is in a position to intercept, inspect and modify network traffic between the iPXE client and the http server: 1. If iPXE makes a new connection to boot.netboot.xyz to retrieve menu.ipxe (or if this file was stored on a different domain from the initial loader in the future) then allowing the first secure connection (index.html) but blocking the second (menu.ipxe) will cause the client to fallback to http, which could then be hijacked (redirected to the attackers own http server) allowing them to provide a config which will (automatically without user interaction?) execute a malicious payload. 2. If iPXE is able to reuse the existing secure connection to boot.netboot.xyz it might still be possible to achieve point 1 if the attacker interrupts (by dropping packets or injecting TCP resets) the secure connection AFTER index.html has been retrieved but BEFORE menu.ipxe has been. Despite it being a secure connection, the attacker can still observe the amount of data being transferred and index.html is of a known size so i think this could be plausible. Suggestions (not in any particular order) that would address this concern 1. Is it possible to provide a combined config where the http fallback will be ignored by clients which loaded it over https? 2. Serve different initial loaders depending upon which protocol the request was made over (might complicate the webserver config) 3. Use a completely different domain or url for people who know their client cannot retrieve the initial loader securely, but for some reason they wish to do it anyway. 4. The least practical, but my favourite nonetheless... Encrypt the web! Simply drop support for http (and don't redirect from http to https either, if anyone gets in the habit of using it then the connection could be hijacked the next time they do as unlike a browser iPXE can't store received HSTS policies for use "next time" they boot it). N.B. Just to put it in perspective for anyone overly concerned about the above, if the attacker is on your local network and DHCP filtering (etc) is not enabled on your switches they could simply respond to your computer's DHCP request before the legitimate DHCP server does and execute any payload they wish without netboot.xyz being involved in any way whatsoever. As useful as it can be, Think about this before blindly enabling PXE as a default boot option (certainly before making it THE default boot option).

kerem closed this issue

2026-03-01 18:34:51 +03:00

kerem commented

2026-03-01 18:34:51 +03:00

Author

Owner

@antonym commented on GitHub (Aug 18, 2017):

Thanks, glad you like it, sorry for the delayed response, I've been really tied up.

Originally I wanted to switch it all to HTTPS only but the problem lies in that the default compile of iPXE does not enable HTTPS support by default. You have to enable HTTPS support as an option and then compile it. This includes default installs of iPXE that a lot of distributions bundle. To someone new to iPXE, they might just assume that netboot.xyz just doesn't work and give up. Maybe that's something that's raised upstream as an option to enable by default (https://github.com/ipxe/ipxe/blob/master/src/config/general.h#L57).

The reason that I currently make an HTTPS connection and then fall back to the HTTP is that I'm currently leveraging the iPXE projects crosscert server which occasionally has some connection issues. I still would like to stand up my own crosscert server but it's just finding time to run through that setup.

I started work to identify which connection had been made on the initial connection and I still plan on adding a secure or insecure connection header at the top of the menu. That way users will know if their connection is secure or not. It's not perfect but it'll at least provide some insight.

@antonym commented on GitHub (Aug 18, 2017): Thanks, glad you like it, sorry for the delayed response, I've been really tied up. Originally I wanted to switch it all to HTTPS only but the problem lies in that the default compile of iPXE does not enable HTTPS support by default. You have to enable HTTPS support as an option and then compile it. This includes default installs of iPXE that a lot of distributions bundle. To someone new to iPXE, they might just assume that netboot.xyz just doesn't work and give up. Maybe that's something that's raised upstream as an option to enable by default (https://github.com/ipxe/ipxe/blob/master/src/config/general.h#L57). The reason that I currently make an HTTPS connection and then fall back to the HTTP is that I'm currently leveraging the iPXE projects crosscert server which occasionally has some connection issues. I still would like to stand up my own crosscert server but it's just finding time to run through that setup. I started work to identify which connection had been made on the initial connection and I still plan on adding a secure or insecure connection header at the top of the menu. That way users will know if their connection is secure or not. It's not perfect but it'll at least provide some insight.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/netboot.xyz#1613

No description provided.

Rows
Columns