Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nmap -A crashes emacs when simple-httpd is running #10

Open
glynnforrest opened this issue Sep 14, 2014 · 8 comments
Open

nmap -A crashes emacs when simple-httpd is running #10

glynnforrest opened this issue Sep 14, 2014 · 8 comments

Comments

@glynnforrest
Copy link

For some reason, nmap -A is crashing emacs consistently when simple-httpd is running.

nmap 6.46 and emacs 24.3.1 on OSX, built with homebrew:

brew install emacs --use-git-head --HEAD --srgb --cocoa

Steps to reproduce:

  • emacs -q (without config)
  • manually load simple-httpd
  • M-x httpd-start
  • nmap -A -T4 localhost

Emacs crashes every time. nmap without -A is completely fine though. nmap -A is a more thorough scan that does OS, version and script detection.

I have absolutely no idea what's going on - if it's unique to my computer, OSX or emacs in general. I'm going to look into it and update this issue if I find anything!

@skeeto
Copy link
Owner

skeeto commented Sep 16, 2014

Emacs 24.3 on Debian Sid also crashes. I get a "Fatal error 6: Aborted",
which in my experience often means something went wrong inside of the
regex engine. It's interesting to see all the hostile requests in the
httpd buffer while the scan runs.

Emacs 24.4 (bleeding edge) survives this scan just fine. Ultimately this
is a bug in Emacs itself since Lisp programs shouldn't be able to cause
an abort like this. Fortunately whatever the problem is, it appears to
be fixed in the upcoming Emacs release. It would still probably be worth
investigating so a regression can be avoided.

@glynnforrest
Copy link
Author

Thank you for taking the time to look into this. I'm glad I'm not alone!

I guess the next step is to find out what input is tripping up emacs and work out a way to reproduce this bug without nmap.

I'll be looking forward to 24.4.

@flexibeast
Copy link

i can reproduce this with locally compiled 24.3.1 on 64-bit Debian Wheezy, using locally compiled nmap 6.46 - it doesn't happen with repo-provided nmap 6.00.

A backtrace, fwiw:

#0  0x00007f59f8303efb in raise () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00000000004e0768 in terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=10) at emacs.c:344
#2  0x00000000004fb223 in emacs_abort () at sysdep.c:2152
#3  0x0000000000498ed8 in multibyte_chars_in_text (ptr=<optimized out>, ptr@entry=0x7fff7271f190 "", nbytes=<optimized out>) at character.c:539
#4  0x000000000053bd28 in make_specified_string (contents=contents@entry=0x7fff7271f190 "", nchars=nchars@entry=-1, nbytes=nbytes@entry=12, multibyte=true) at alloc.c:2141
#5  0x0000000000512d8f in Fdirectory_file_name (directory=43937729) at fileio.c:617
#6  0x0000000000554ebd in eval_sub (form=form@entry=44068006) at eval.c:2143
#7  0x000000000055486e in apply_lambda (fun=8743269, args=<optimized out>) at eval.c:2878
#8  0x0000000000554c42 in eval_sub (form=<optimized out>) at eval.c:2218
#9  0x0000000000554d24 in eval_sub (form=<optimized out>) at eval.c:2128
#10 0x0000000000557d98 in Flet (args=15397014) at eval.c:884
#11 0x0000000000555040 in eval_sub (form=<optimized out>) at eval.c:2091
#12 0x0000000000555235 in Fprogn (args=8135) at eval.c:360
#13 0x0000000000557eb9 in Flet (args=15396662) at eval.c:914
#14 0x0000000000555040 in eval_sub (form=<optimized out>) at eval.c:2091
#15 0x0000000000555235 in Fprogn (args=8135) at eval.c:360
#16 0x0000000000555040 in eval_sub (form=<optimized out>) at eval.c:2091
#17 0x0000000000555235 in Fprogn (args=8135) at eval.c:360
#18 0x0000000000555578 in funcall_lambda (fun=fun@entry=15541190, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fff7271f9b0) at eval.c:3003
#19 0x000000000055489c in apply_lambda (fun=15541190, args=<optimized out>) at eval.c:2887
#20 0x0000000000554c42 in eval_sub (form=<optimized out>) at eval.c:2218
#21 0x0000000000558032 in FletX (args=43862246) at eval.c:819
#22 0x0000000000555040 in eval_sub (form=<optimized out>) at eval.c:2091
#23 0x0000000000555235 in Fprogn (args=8135) at eval.c:360
#24 0x0000000000555578 in funcall_lambda (fun=43865574, nargs=nargs@entry=2, arg_vector=arg_vector@entry=0x7fff7271fd78) at eval.c:3003
#25 0x000000000055581b in Ffuncall (nargs=nargs@entry=3, args=args@entry=0x7fff7271fd70) at eval.c:2839
#26 0x00000000005567ed in Fapply (nargs=nargs@entry=2, args=args@entry=0x7fff7271fe20) at eval.c:2312
#27 0x0000000000555d00 in apply1 (fn=43702562, arg=<optimized out>) at eval.c:2546
#28 0x0000000000553f5b in internal_condition_case_1 (bfun=bfun@entry=0x58e6b0 <read_process_output_call>, arg=44502838, handlers=handlers@entry=12135426, 
    hfun=hfun@entry=0x58e630 <read_process_output_error_handler>) at eval.c:1327
#29 0x000000000058e29d in read_process_output (proc=proc@entry=17786821, channel=channel@entry=10) at process.c:5221
#30 0x0000000000592036 in wait_reading_process_output (time_limit=time_limit@entry=28, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, 
    wait_for_cell=<optimized out>, wait_proc=wait_proc@entry=0x0, just_wait_proc=just_wait_proc@entry=0) at process.c:4852
#31 0x0000000000422568 in sit_for (timeout=timeout@entry=112, reading=reading@entry=true, display_option=display_option@entry=1) at dispnew.c:5978
#32 0x00000000004ebbfe in read_char (commandflag=1, nmaps=nmaps@entry=2, maps=maps@entry=0x7fff727218a0, prev_event=12083746, used_mouse_menu=used_mouse_menu@entry=0x7fff727219b3, 
    end_time=0x0, end_time@entry=0x7fff727218a0) at keyboard.c:2669
#33 0x00000000004ed513 in read_key_sequence (keybuf=keybuf@entry=0x7fff72721a90, prompt=12083746, dont_downcase_last=dont_downcase_last@entry=false, 
    can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, bufsize=30) at keyboard.c:9231
#34 0x00000000004ef50e in command_loop_1 () at keyboard.c:1459
#35 0x0000000000553e13 in internal_condition_case (bfun=bfun@entry=0x4ef320 <command_loop_1>, handlers=12135426, hfun=hfun@entry=0x4e4b80 <cmd_error>) at eval.c:1289
#36 0x00000000004e331e in command_loop_2 (ignore=ignore@entry=12083746) at keyboard.c:1168
#37 0x0000000000553cf0 in internal_catch (tag=<error reading variable: Cannot access memory at address 0x1fa7>, func=func@entry=0x4e3300 <command_loop_2>, arg=12083746) at eval.c:1060
#38 0x00000000004e4667 in command_loop () at keyboard.c:1147
#39 recursive_edit_1 () at keyboard.c:779
#40 0x00000000004e4985 in Frecursive_edit () at keyboard.c:843
#41 0x0000000000418b5f in main (argc=1, argv=<optimized out>) at emacs.c:1528

@flexibeast
Copy link

i have a tcpdump capture file of the packets exchanged in the leadup to the crash; might that be of use?

@bonsaiviking
Copy link

As an Nmap developer, I can pretty much guarantee that it's the service version detection engine that is causing the crash. To isolate the problem, try these commands:

  • nmap -sV --version-trace localhost - watch for the probe that gets sent immediately prior to "Got nsock CONNECT response with status ERROR - aborting this service"
  • nmap -sVC --script-trace localhost - If the previous command did not crash it, this one probably will. Finding the offending packet will be a bit harder, since scripts run in parallel and the engine doesn't stop when the port becomes closed. Still, it will be the last packet with any data in it.

Please post the name of the service probe ("Service scan sending probe XXX") or the content of the script packet so that we can perhaps modify it to crash fewer services. Thanks!

@flexibeast
Copy link

Thanks for your help!

The first command is enough to cause the crash:

Service scan sending probe DNSStatusRequest to 127.0.0.1:8080 (tcp)
NSOCK INFO [52.1080s] nsock_read(): Read request from IOD #75 [127.0.0.1:8080] (timeout: 5000ms) EID 1970
NSOCK INFO [52.1080s] nsock_trace_handler_callback(): Callback: WRITE SUCCESS for EID 1963 [127.0.0.1:8080]
NSOCK INFO [52.1100s] nsock_trace_handler_callback(): Callback: READ EOF for EID 1970 [127.0.0.1:8080]
NSOCK INFO [52.1100s] nsi_delete(): nsi_delete (IOD #75)
NSOCK INFO [52.1100s] nsi_new2(): nsi_new (IOD #76)
NSOCK INFO [52.1100s] nsock_connect_tcp(): TCP connection requested to 127.0.0.1:8080 (IOD #76) EID 1976
NSOCK INFO [52.1100s] nsock_trace_handler_callback(): Callback: CONNECT ERROR [Connection refused (111)] for EID 1976 [127.0.0.1:8080]
Got nsock CONNECT response with status ERROR - aborting this service

@bonsaiviking
Copy link

@flexibeast Here's the probe that is sent:

Probe TCP DNSStatusRequest q|\0\x0C\0\0\x10\0\0\0\0\0\0\0\0\0|

You should be able to reproduce with this one-liner:

echo -ne '\0\x0C\0\0\x10\0\0\0\0\0\0\0\0\0' | nc 127.0.0.1 8080

@flexibeast
Copy link

@bonsaiviking Yep, that one-liner reproduced the crash for me! Thanks for your help with this. :-)

conao3 pushed a commit to conao3/emacs-web-server that referenced this issue Feb 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants