* * * * *
It's more like computer security theater than actual security
> In w3m, to edit a form textarea,
>
> -----[ C ]-----
> ...
> f = fopen(tmpf, "w");
> if (f == NULL) {
> /* FIXME: gettextize? */
> disp_err_message("Can't open temporary file", FALSE);
> return;
> }
> if (fi->value)
> form_fputs_decode(fi->value, f);
> fclose(f);
>
> if (exec_cmd(myEditor(Editor, tmpf, 1)->ptr))
> goto input_end;
> ...
> -----[ END OF LINE ]-----
>
> exec_cmd is some setup and teardown around a system(3) call with the user's
> editor and the temporary file. This is not good for security, as it allows
> w3m to execute by default anything. One tentative improvement would be to
> only allow w3m to execute a wrapper script, something like
>
> -----[ C ]-----
> #!/bin/sh
> exec /usr/bin/vi -S "$@"
> -----[ END OF LINE ]-----
>
> or some other restricted editor that cannot run arbitrary commands nor read
> from ~/.ssh and send those files off via internet connections. This is
> better, but why not disallow w3m from running anything at all?
>
> -----[ C ]-----
> if (pledge(
> "cpath dns fattr flock inet proc rpath stdio tty unveil wpath",
> NULL) == -1)
> err(1, "pledge");
> -----[ END OF LINE ]-----
>
> Here we need the “proc” (fork) allow so downloads still work, but “exec” is
> not allowed. This makes it a bit harder for attackers to run arbitrary
> programs. An attacker can still read various files, but there are also
> unveil restrictions that very much reduce the access of w3m to the
> filesystem. An attacker could make DNS (Domain Name Service) and internet
> connections, though fixing that would require a different browser design
> that better isolates the “get stuff from the internet” parts from the “try
> to parse the hairball that is HTML (HyperText Markup Language)” code,
> probably via imsg_init(3) on OpenBSD, or differently complicated to
> download to a directory with one process and to parse it with another. That
> way, a HTML security issue would have a more difficult time in getting out
> to the interwebs.
>
“Security Hoop [1]”
What I find annoying is the lack of any type of attack as an example. It's
always “data from da Intarwebs bad!” without regard to how it's bad. The
author just assumes that hackers out there have some magical way of executing
code on their computer just by the very act of downloading a file. The
assumption that some special sequence of HTML can open a network connection
to some control server in Moscow or Beijing or Washington, DC (District of
Columbia) and siphon off critical data is just … I don't know, insane to me.
Javascript, yes, I can see that happening. But HTML?
And then I recall the time that Microsoft added code to their programs to
scan JPEG (Joint Photographic Experts Group) images for code and
automatically execute it, and okay, I can see why maybe the cargo cult
security mumbo-jumbo exists.
What I would like to see how opening a text editor with the contents of an
HTML <TEXTAREA> could be attacked. What are the actual attack surfaces? And
no, I won't accept “just … bad things, man!” as an answer. What, exactly?
One possible route would be ECMA (European Computer Manufacturers
Association)-35 [2] escape sequences, specifically the DCS (Device Control
String) and OSC (Operating System Command) sequences (which could be used to
control devices or the operating system respectively), although I don't know
of any terminal emulator today that supports them. Microsoft did add an
escape sequence to reprogram the keyboard (ESC “[” key-code “;” string “p”)
but that's in the “private use” area set aside for vendors.
This particular attack vector might work if the editor is running under a
terminal or terminal emulator that support it, and the editor in question
doesn't remove or escape the raw escape sequence codes. I tried a few text
editors on the following text (presented as a hexadecimal dump to show the
raw escape sequence):
-----[ data ]-----
00000000: 54 68 69 73 20 69 73 20 1B 5B 34 31 6D 72 65 64 This is .[41mred
00000010: 1B 5B 30 6D 20 74 65 78 74 2E 0A 0A .[0m text...
-----[ END OF LINE ]-----
None of the editors I tried (which are all based on the command line and
thus, use escape sequences themselves to display text on a terminal)
displayed red text. The escape sequence wasn't run as an escape sequence.
Another attack might embedding editor-specific commands within the text. This
is a common aspect of some editors, like vi [3]. And I can see this being
concerning, especially if the commands one can set in a text file include
accessing arbitrary files or running commands.
A third attack could be an attempt to buffer overflow the editor, either by
sneaking in a huge download (like say, a file with a single one gigabyte
line) or erroneous input (for example, if the editor expects a line to end
with a CR and LF, send an LF then CR). Huge input is a bit harder to hide,
but suble erroneous input could cause issues.
This is why I feel such articles are bad—by not talking about actual threats
they enforce a form of “learned helplessness.” Everything is dangerous and we
must submit to onerous measures to keep ourselves safe. Sprinkling calls to
pledge() [4] aren't the answer. Yes, it helps, but not thinking critically
about security leads to a worse experience overall, such as having to
manually edit a file which would still be subject to all three of the above
attacks anyway. By identifying the attacks, then a much better way to
mitigate the attacks could be found (in this case, an editor that strips out
escape sequences and does not support embedded commands; and yes, I know I
have a minority opinion here—sigh).
And to address the bit about parsing HTML—is parsing really that fraught with
danger? All you need to parse HTML is to follow the explicit (and in
excruciating detail) HTML5 specification [5]. How hard can that be?
[1] gemini://thrig.me/blog/2025/01/03/security-hoop.gmi
[2]
https://en.wikipedia.org/wiki/ANSI_escape_code
[3]
https://vimhelp.org/options.txt.html#auto-setting
[4]
https://man.openbsd.org/pledge.2
[5]
https://html.spec.whatwg.org/
Email author at
[email protected]
