Osmosis: the screen names one asset and the signature commits to another

[BitHighlander]

Reproduced on signed v7.14.1 (sha256 f40fe1b74949a9e091269536b27cd53bbb8a5c1c428a6c36ff7d5c6bf6845f46, key slots 1/2/3).

What happens

Send an Osmosis MsgSend of 123456789012345678 uion:

sent	123456789012345678 uion
on screen	123456790519087104.000000
signed	"denom":"uosmo"

Two independent defects in one confirmation.

1. The amount is wrong past the 8th significant digit

fsm_msg_osmosis.h:143   float amount = atof(msg->send.amount);
fsm_msg_osmosis.h:151   snprintf(..., "%.6f %s", amount, denom);

float is 32-bit. float32(123456789012345678) is exactly 123456790519087104,
which is what the OLED shows — the digits after the 8th are wrong, not
rounded. The .000000 tail is on a denom that was never divided, because only
uosmo is decimalised.

2. The signed document names a different asset than the screen

osmosis.c:78    "\",\"denom\":\"uosmo\"}]"
osmosis.c:131   "\"amount\":[{\"amount\":\"%s\",\"denom\":\"uosmo\"}]"

uosmo is hardcoded into the amino document that gets signed, regardless of the
denom that was displayed. The screen is built from the host's denom; the
signature is built from a constant. They are not the same source, so they can
disagree — and for any non-uosmo denom they do.

The device signed.

Fix

• decimalise only uosmo; print every other denom as the exact signed integer
  next to the exact denom, with no .000000 tail
• build the amino document from the same denom that was displayed

Fixed in the 7.14.2 security line.