[Rd] R prompt updates are not validated

[Tomas Kalibera]

On 4/18/19 11:07 PM, Jack Wasey wrote:
> I was trying to get an interactive R prompt with the current working directory. I reviewed R source 'main.c' and 'options.c', and saw that a 20 char buffer is used when in Browse debugging mode, but that no other validation is done on the length of the prompt option.
There is no limit enforced on the length of the prompt option. There is 
nothing wrong about accepting strings of unlimited length, when they are 
handled properly. I don't see any problem in how the prompt string is 
handled in the present code base. The only reason to add such limit may 
be to hide the readline issue you found, but perhaps it would be better 
to solve that on the readline side, unless you have a realistic 
reproducible example to trigger the problem.
> This hangs R, or takes extremely long to return:
>
> # R --vanilla
> big <- paste(sample(LETTERS, size = 1e7, replace = TRUE), collapse = "")
> options(prompt = big)
>
> Running R with gdb and interrupting to get backtraces shows that 'pushReadLine' in 'unix/sys-std.c' results in a chain of libreadline calls, including, in my case at least, UTF-8 and a lot of __strlen_avx2 activity. 'R_PromptString' in 'main.c' should check prompt is a reasonable length, as well as a check when setting the prompt in 'options.c'. This may be a readline bug, too? I watched it do nothing for a while, it didn't seem to accumulate much or any new memory while watching 'top', but did max one core of CPU.

I can reproduce this issue with readline on Ubuntu and Fedora, 
rl_callback_handler_install() takes very long, spending a lot on time in 
encoding conversions, and for large inputs corrupts memory. On macOS 
with editline I could get long prompts working fine (fast and without 
crashing). I don't see how this could be a problem in R, it seems to be 
in readline: if you or anyone find it to be a problem worth spending 
time on, I would suggest creating a small standalone C example to 
trigger it and file a bug against readline.

> I've searched R-devel and see minimal discussion of security threats in R. Has anybody fuzzed R with data or source files? As R grows in popularity, I hope there is some pro-active security work going on, which I understand may not always best be done on a public mailing list.

Keep in mind that R by design lets you run arbitrary code on the machine 
without any restriction (e.g. via "system", "library", "dyn.load"), and 
there is no API in R to restrict access to those and similar functions. 
So, there is no point in exploiting say a buffer overflow bug. Of 
course, a buffer overflow bug is still a correctness problem and will be 
fixed if found and reported.

Tomas

>
> Jack Wasey
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel