CLOSED: [2018-07-24 Tue 20:57]
:PROPERTIES:
:CREATED:  [2018-07-24 Tue 18:50]
:ID:       2018-07-24-executable-guessing
:END:
:LOGBOOK:
- State "DONE"       from "STARTED"    [2018-07-24 Tue 20:57]
:END:

This is the first article of my [[id:2018-06-05-bad-design-decisions][Design Decisions series]].

There was a very interesting thing related to command resolving in
Microsoft Windows. This can be explained using an example. Let's say a
user wants to start the command =c:\Program
Files\emacs-25\bin\epdfinfo.exe /h=. What is the [[https://en.wikipedia.org/wiki/Executable][executable]] and what
are the [[https://en.wikipedia.org/wiki/Command-line_argument#Arguments][command line arguments (or parameters)]] here? In theory, we
have three possibilities:

1. Look out for =c:\Program.exe=, =c:\Program.com=, or
   =c:\Program.bat= and interpret =Files\emacs-25\bin\epdfinfo.exe= as
   the first command line parameter and =/h= as the second parameter.
2. Start =c:\Program Files\emacs-25\bin\epdfinfo.exe= and use =/h= as
   a command line parameter.
3. Look out for =c:\Program Files\emacs-25\bin\epdfinfo.exe /h.exe=,
   =c:\Program Files\emacs-25\bin\epdfinfo.exe /h.com=, or =c:\Program
   Files\emacs-25\bin\epdfinfo.exe /h.bar=.

To be honest, I don't know if the third option was ever possible. In
contrast, the first two options were actually possible. So how did
Microsoft knew what executable to start and what parameter to use?

They did not. Microsoft's solution was astonishing: They simply tried.

*** Trying Instead Of Knowing

Microsoft Windows was guessing, what executable to start. That's
right: for many years, Microsoft Windows had a [[https://en.wikipedia.org/wiki/Trial_and_error][trial-and-error]] method
to parse command line executions. For a technical savvy person, this
is a really weird one.

Microsoft just tried, if there is an executable like =c:\Program.exe=.
When there was no =exe=, =com=, or =bat= file, they continued parsing and
tried the next possible candidate which is =c:\Program
Files\emacs-25\bin\epdfinfo.exe= in our example above.

*** Side-Effects Galore

This had consequences: any =c:\Program.exe=, =c:\Program.com=,
or =c:\Program.bat= could turn a Windows computer useless. When
somebody was able to place such a file on a Windows computer, it got
executed any time the trial-and-error algorithm was applied.

For bad guys, this was also a formidable wrapper-method to control the
computer. Such an executable was able to track all program invocations
and could decide to really execute the command in question or to
choose a different one according to malicious rules.

Please note that back-then, people were constantly working as local
Administrator. There was no [[https://en.wikipedia.org/wiki/User_Account_Control][UAC]] around which allows temporary doing
things as Administrator. For installing programs, you really had to
log-out as user and log-in as Administrator. After installing, you had
to log-out as Administrator and log-in as user again. Of course, this
resulted in almost averybody working as Administrator. And when you
are Administrator, every tool has the ability to place a
=c:\Program.exe= file.

And if the technical reasons above are not enough to refrain from
creating such an awful algorithm: it's simply poor design beyond
understanding.

*** Current Situation and Further Sources

I can not confirm the wrong behavior with XP Pro 2002 SP3 any more.
More modern Windows versions corrected this issue as well. Nowadays, a
command containing spaces has to be put into double quotes.

However, the trial-and-error algorithm was the default and standard
behavior on Windows operating systems for many years. It was not well
known among normal users and it was not only an annoyance but also a
harmful security threat to all Windows users.

You can find out more on this issue by visiting [[https://xato.net/the-program-exe-problem-635d66e89c14?gi=2b13d63dd4e2][this source from 2007]]
that refers to [[https://www.securityfocus.com/columnists/301][this page from 2005]]. The localization of the program
folder (a very bad idea in itself) and the guessing issue are
discussed [[http://www.beginningtoseethelight.org/ntsecurity/index.htm#DAD8636F687BF15B][on this page from 2005]]. People who are able to read Japanese
might enjoy [[http://www.sec-pro.net/newsletter/20121112.html][this article from 2012]] which explains the negative impacts
as well.

So how did other operating systems deal with this issue? All other
operating systems require the user to escape spaces in command lines
that are not a component separator with a backslash. Unfortunately,
Microsoft is using the backslash character as the path separator. This
had other negative impacts and it will be discussed in another blog
article.

*** Lessons Learned
:PROPERTIES:
:END:

In my opinion, we should learn from this example:

- Never guess, make everything explicit.
- Learn from already established systems and look how they solve the
  same issue. You can do better but you should not do worse.
- When something feels wrong, it is wrong.