[erlang-bugs] Denial-of-service vulnerability in erlang's group.erl

[Stefan Zegenhagen]

Hi Fred,

> I'm asking this seriously, and not as some kind of snark. I can see the
> OOM error being the result of honest mistakes, but I can't imagine
> connecting to a node, seeing a shell, and saying "yes, I will overload
> it by streaming data" instead of trying any of the following:


I'm very happy that the discussion has started again and hope for open
ears this time.

I'm talking about the case where custom shells come into play. We have
devices where a custom command line interface (CLI) was implemented to
allow authorized customers to configure/control the device. The CLI is
available via both, SSH and a serial port.

Such a custom CLI is not uncommon in the computer world. Many databases
offer a CLI to run SQL queries, Routers offer a CLI to configure
networking, ... They all have in common that the user does not get
system privileges or a system shell prompt and is restricted to a
certain set of self-defined commands.

The user that is using our CLI has no access whatever to an erlang shell
and is restricted to executing our custom commands allowed by the CLI.
He cannot simply execute arbitrary code, he cannot simply type arbitrary
commands, he cannot arbitrarily interfere with the system.

The user has to authenticate to the device by means of username/password
(over the serial port) or whatever method SSH allows.

What sounds like a bug to me is that the user is able to crash our
system, using our CLI system and *NOT THE ERLANG SHELL*, just by sending
megabyte-long lines to the CLI (where a prompt is waiting for input),
and we can do nothing against it except reimplementing group.erl. While
we could do that for our shell implementation over the serial port
easily (we start group.erl in our code), the situation is a little more
complicated for SSH. There is no chance to replace group.erl without
additionally patching the Erlang SSH application.

Two examples:
1.) The user connects a cable to the serial port and is asked to login.
He sends megabytes of data, the device crashes reliably.
2.) A user with read-only permissions connects to our device via SSH. He
has no permission to reboot the system. By sending tons of characters
over SSH he reboots the device reliably.

To summarize:
      * I'm not talking of arbitrary code execution possiblities.
      * I'm talking of a "hardended", custom CLI implementation.
      * No regular access to the erlang shell.
      * Instead of logging on to our CLI, the user just sends
        megabyte-long lines to the device and it crashes as reliably as
        the sun rises in the morning.
      * Various misbehaviours of the software act as precursor to the
        final crash/reboot, including the ones I already mentioned:
        system slowdown, OOM killer killing non-erlang services, erlang
        crash, misbehaving erlang applications unrelated to the CLI.
      * We cannot simply amend the situation.
      * The device is unable to fulfil its designated task, the attacker
        is able to make the device "deny the service".

I would call this a bug in group.erl, and the only thing I want to
request is an optional method to circumvent the problem (that is not
esotheric or academic for us, but a real, practical problem) for the
services where this is needed (our CLI). This would most easily be
achieved using a new io:setopts() option.

How overlong lines are reported back to the application utilizing
group.erl is a matter of taste, but it is likely that some kind of
error-abort of the io_request should be done to stop further processing
of that line.


Kind regards,

-- 
Dr. Stefan Zegenhagen

arcutronix GmbH
Garbsener Landstr. 10
30419 Hannover
Germany

Tel:   +49 511 277-2734
Fax:   +49 511 277-2709
Email: stefan.zegenhagen@REDACTED
Web:   www.arcutronix.com

*Synchronize the Ethernet*

General Managers: Dipl. Ing. Juergen Schroeder, Dr. Josef Gfrerer -
Legal Form: GmbH, Registered office: Hannover, HRB 202442, Amtsgericht
Hannover; Ust-Id: DE257551767.

Please consider the environment before printing this message.