Heads 1.3.1 boot menu bug

Using a x230 with default heads 1.3.1, nitrokey inserted and updated checksums, I noticed the following bug:

  1. Navigate the heads menu to → Boot Options → Boot menu
  2. Try to exit the menu again with indicated “a” (abort) key. It won’t work (in my case at least). The only key working appears ESC.
  3. After the main heads menu reappears, it will show a HOTP mismatch.
  4. try updating HOTP/TOTP from the menu, a TOTP mismatch (yellow screen) will appear too.
  5. poweroff and on → all ok again.

It’s reproducible for me. It is not a severe as a bug, but in circumstances the heads alerting (color changes to red after two tries) may misguide a user to reset the TPM or so.

I had a brief search in the forum and on heads’ github, but did not see a related bug, so I drop it here.

2 Likes

Could also reproduce the issue. Traced the behavior as follows:

The menu is being displayed using whiptail. Pressing ESC exits it with error code 255. This leads to executing die. This calls echo with the error message and exits kexec-select-boot with 1.

The parent script then calls show_main_menu at the end of the file which executes unseal-hotp (saved as variable $HOTP) which presumely alters PCR values and the HOTP changes.

while true; do
  show_main_menu
done

Potential Fix for a button not working:
After the following line just repeat lines 126-128 where the button a is handled.

This still would alter the PCR values and thus the HTOP. I think this is intentional. The HTOP/TOTP should check whether the boot to menu was not altered. And aborting the boot menu alters the “clean” state.

2 Likes

Interesting find. So, a parsed 'a’bort would still let it die, when this serves no safe purpose and should rather be 'r’eboot.
What I still don’t get is why the HTOP fails first upon ESC to the main menu, but the TOTP only after refreshing both (when the PCR mismatch error is finally shown). But ok, I am still finding my way through it. I guess I’ll create a kexec_menu.txt as per heads wiki sometime and see what happens then.

@nku thanks for the report! In general you could also open an issue here Issues · Nitrokey/heads · GitHub but this way is also fine. I could reproduce the Abort issue in our Firmware 1.4-2-g9c5e572 . But the HOTP Issue I can’t reproduce, So maybe this is a different issue just in 1.3.1. This (HOTP mismatch) actually should not happen, since no file is changed, so it sounds like a bug. When we have a fix I will link it here