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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
