http direct to terminals?
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
base-files (Ubuntu) |
Fix Released
|
Critical
|
Dustin Kirkland |
Bug Description
Hi Dustin,
Some recent changes introduced what looks to be a serious problem:
http://
-SERVER="https:/
+# White space separated list of 0 to many news services
+SERVER="http://
[...]
+ if curl --connect-timeout "$WAIT" --max-time "$WAIT" -A "$USER_AGENT" -o- "$s" >"$NEWS" 2>"$ERR"; then
+ echo
+ # At most, 2 lines of at most 80 characters
+ cat "$NEWS" | tail -n 2 | cut -c -80
This allows any network man-in-the-middle attacker, DNS response forger, or BGP forger, to write 160 raw bytes directly to terminals.
The previous version wasn't good (open for abuse by anyone who could trick one of the myriad x.509 Certificate Authorities to mis-issue a certificate) but this version is open for abuse by significantly more attackers.
While most terminals are reasonably safe against outright maliciousness this has been a recurring exploitation theme for twenty years, and even what is "safe" for them to display could be wildly confusing to users unfamiliar with maliciously controlled terminals. (And users have wide tastes in terminals, some are fairly brittle.)
cat(1) does not do any filtering for 'safe' display of arbitrary inputs. less(1) does, assuming -r is not in LESS environment variable or the less(1) command line. If you wish to keep the pipeline, perhaps tr(1)'s -d flag could be useful.
On a related note, is there a reason why the motd.ubuntu.com server can't do HTTPS?
Thanks
Changed in base-files (Ubuntu): | |
assignee: | nobody → Dustin Kirkland (kirkland) |
status: | Confirmed → In Progress |
This looks a lot like a call-home backdoor.