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

[Fred Hebert]

What are the risks of someone being able to gain access to group.erl,
where killing the node through OOM because of end of lines is the most
practical approach?

For the SSH module, the group.erl module is used with custom shells
implementations, and I've never seen Erlang code that allowed arbitrary
code execution without being ultimately very easy to crash in all kinds
of ways.

If you can run simple expressions such as sending messages, or can
construct binaries, chances are you can kill a node with far more ease
than you can by overflowing group.erl.

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:

- halt(0)
- init:stop()
- c:q()
- init ! {stop,stop}
- apply(Mod, Fun, ...) from any of the previous options
- {init,[0]}:stop()
- lists:duplicate(99999999999999999999999999999, hello)
- <<0:100000000000000000/binary>>.
- << <<X,1>> || <<X:0, _/binary>> <= <<1,2,3>> >>
- os:cmd("..."),
- all sorts of binary_to_term tricks
- and so on

Which would take far less effort and far less bandwidth to accomplish.
You might also want to cripple systems by using sys:suspend/1-2 on all
the processes you can get your hand on, either through using
`processes()` or dynamically building pids from binaries.

So is there a case where input frequently makes it to group.erl
*without* the user having the ability to execute arbitrary code of some
sort if it ever succeeds? If not, then I don't think limiting the input
will accomplish much. I'm curious about the cases that would use
group.erl without wanting to evaluate input.

Regards,
Fred.

On 06/25, Stefan Zegenhagen wrote:
> Dear all,
> 
> All input routines in lib/kernel/src/group.erl suffer from a
> denial-of-service vulnerability that can easily be used by an attacker
> to randomly crash erlang applications, the erlang VM or other system
> processes on the same computer.
> 
> The group.erl I/O server offers line-editing functionality (using
> edlin.erl) for all input. It therefore applies line-editing until a
> newline character was received and the current input line is finished.
> Only then the supplied end-of-input detection routines are called, that
> differ for the get_chars, get_until, get_line, and get_password
> commands.
> 
> Any attacker that has access to an input prompt serviced by group.erl
> can send several megabytes of characters to the input prompt without a
> newline in between. Thereby he can cause the Erlang VM to
>      A.  consume all available memory and eventually have the Linux OOM
>         (Out-Of-Memory) killer randomly kill system processes even other
>         than the Erlang VM
>      B. consume all available CPU power and slow the system down
>      C. cause timeout errors in unrelated Erlang applications by the
>         amount of garbage collection going on
>      D. cause the Erlang VM to crash (was observed on a live system, but
>         a crash dump could not be saved).
> 
> Currently, it is not possible to circumvent this behaviour (except by
> re-implementing group.erl in any application using it). This is because
> all of the end-of-input searching routines are only ever called *AFTER*
> a complete, newline-terminated line has been read. Therefore, get_until
> and get_chars won't help.
> 
> A meaningful solution is to allow users of group.erl to optionally limit
> the maximum line length it will handle. If this maximum line length is
> reached, group.erl should report an error response to the I/O request.
> This would likely be implemented as a new set_opts option (although not
> a global one affecting all group.erl process instances). This way, the
> current behaviour would be retained and compatibility problems are not
> to expect.
> 
> Please note that group.erl is *NOT EXCLUSIVELY* used by the erlang
> shell. Erlang's SSH application uses group.erl as I/O server for its SSH
> server implementation. Several devices may have a specific command line
> interface (CLI) running on serial ports. Other uses of group.erl are
> imaginable.
> 
> 
> 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.
> 
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs