4 ms·

Things like this (terminal add-ons like graphical layers and image viewers and so on) are only going to end badly. What's so special about the terminal is the

by rsync 9y ago

Things like this (terminal add-ons like graphical layers and image viewers and so on) are only going to end badly. What's so special about the terminal is the immunity the user has to hostile character strings. When I view a webpage in lynx or read an email in (al)pine, there is no string that could be injected to harm me - I am immune to viruses and javascript and weird CSS and so on. I can open up an infected document or view a phishing email. In short, the well-behaved terminal does nothing but display text in your character set. It does not interpret and it does not execute and it certainly doesn't call GUI APIs to draw buttons and display videos. This is a door best left unopened ...

chungy 9y ago
Pretending that terminal or command line applications are immune to a very common mode of attack, even to them, is itself dangerous thinking. This could potentially add a new attack surface, sure, but don't think that without it, exploits aren't possible.
- pwdisswordfish2 9y ago
  Who is writing those exploits? He is citing a reduced attack surface that is easier to manage. Not "immunity". It is a choice between being low hanging fruit or not being low hanging fruit. With enough effort, any fruit is accessible. However it is immature internet forum behavior to chide someone for choosing not to be low hanging fruit.
egwynn 9y ago
I’m not sure I follow you. Unless I’ve read it totally wrong, this thing is basically just xdialog for macOS with some fancy dress-up. I don’t see how it exposes a novel attack vector.
ohazi 9y ago
> What's so special about the terminal is the immunity the user has to hostile character strings. I have a handful of escape codes that beg to differ...
rnhmjoj 9y ago
> there is no string that could be injected to harm me Unfortunately that's not true at all. There are many instances of arbitrary code execution gained though a terminal emulator, with escape sequences[1] being the most common. For example exploiting common "git prompts"[2] scripts or running `strings` on a binary[3]. [1]: https://unix.stackexchange.com/a/15210 https://unix.stackexchange.com/a/15210 [2]: https://github.com/njhartwell/pw3nage https://github.com/njhartwell/pw3nage [3]: http://lcamtuf.blogspot.it/2014/10/psa-dont-run-strings-on-untrusted-files.html http://lcamtuf.blogspot.it/2014/10/psa-dont-run-strings-on-u...
- rsync 9y ago
  Thank you for bringing up the 'strings' problem - something I had forgotten about. It's worth noting, however, that there is nothing inherently dangerous about a strings-like utility. Rather, it is GNU strings which has unexpected complexity: "Perhaps simply by the virtue of being a part of that bundle, the strings utility tries to leverage the common libbfd infrastructure to detect supported executable formats and "optimize" the process by extracting text only from specific sections of the file. Unfortunately, the underlying library can be hardly described as safe: a quick pass with afl (and probably with any other competent fuzzer) quickly reveals a range of troubling and likely exploitable out-of-bounds crashes due to very limited range checking" ... which is the very issue I'm warning against, just at a different layer of abstraction ...
sly010 9y ago
There is two problems with that argument: - Terminals are the worth offenders when it comes to special characters and encoding issues. - GUIs are not inherently injectable. That said, I still things it's a weird idea. There are much better ways to gain efficiencies (e.g. shells)
pavlov 9y ago
I'm not sure what you mean. Termipal is just an external program, it's not going to be automatically launched by the Terminal. It's like any other interpreter you might run from your scripts -- it's your responsibility to ensure the input is safe.

by rsync 9y ago

chungy 9y ago

Pretending that terminal or command line applications are immune to a very common mode of attack, even to them, is itself dangerous thinking. This could potentially add a new attack surface, sure, but don't think that without it, exploits aren't possible.

pwdisswordfish2 9y ago
Who is writing those exploits? He is citing a reduced attack surface that is easier to manage. Not "immunity". It is a choice between being low hanging fruit or not being low hanging fruit. With enough effort, any fruit is accessible. However it is immature internet forum behavior to chide someone for choosing not to be low hanging fruit.

egwynn 9y ago

I’m not sure I follow you. Unless I’ve read it totally wrong, this thing is basically just xdialog for macOS with some fancy dress-up. I don’t see how it exposes a novel attack vector.

ohazi 9y ago

> What's so special about the terminal is the immunity the user has to hostile character strings. I have a handful of escape codes that beg to differ...

rnhmjoj 9y ago

> there is no string that could be injected to harm me Unfortunately that's not true at all. There are many instances of arbitrary code execution gained though a terminal emulator, with escape sequences[1] being the most common. For example exploiting common "git prompts"[2] scripts or running `strings` on a binary[3]. [1]: https://unix.stackexchange.com/a/15210 https://unix.stackexchange.com/a/15210 [2]: https://github.com/njhartwell/pw3nage https://github.com/njhartwell/pw3nage [3]: http://lcamtuf.blogspot.it/2014/10/psa-dont-run-strings-on-untrusted-files.html http://lcamtuf.blogspot.it/2014/10/psa-dont-run-strings-on-u...

rsync 9y ago
Thank you for bringing up the 'strings' problem - something I had forgotten about. It's worth noting, however, that there is nothing inherently dangerous about a strings-like utility. Rather, it is GNU strings which has unexpected complexity: "Perhaps simply by the virtue of being a part of that bundle, the strings utility tries to leverage the common libbfd infrastructure to detect supported executable formats and "optimize" the process by extracting text only from specific sections of the file. Unfortunately, the underlying library can be hardly described as safe: a quick pass with afl (and probably with any other competent fuzzer) quickly reveals a range of troubling and likely exploitable out-of-bounds crashes due to very limited range checking" ... which is the very issue I'm warning against, just at a different layer of abstraction ...

sly010 9y ago

There is two problems with that argument: - Terminals are the worth offenders when it comes to special characters and encoding issues. - GUIs are not inherently injectable. That said, I still things it's a weird idea. There are much better ways to gain efficiencies (e.g. shells)

pavlov 9y ago

I'm not sure what you mean. Termipal is just an external program, it's not going to be automatically launched by the Terminal. It's like any other interpreter you might run from your scripts -- it's your responsibility to ensure the input is safe.