assembly cgi program printing garbage

Laserbeak · 07-07-2017, 02:32 PM

Quote:

Originally Posted by scasey

Yes, that's true. Point is that the first thing from the script needs to be a "Content-Type:..." header

Yep! But you made it sound like you HAD to send text/html. Just pointing that out... no prob.

NevemTeve · 07-07-2017, 02:48 PM

> I tried to assemble it and it wouldn't run.
How did you try to assemble it? What command did you use?

Laserbeak · 07-07-2017, 04:41 PM

Quote:

Originally Posted by NevemTeve

> I tried to assemble it and it wouldn't run.
How did you try to assemble it? What command did you use?

Among others (including yasm)... this seemed most promising but it still didn't run:

Code:

nasm -f macho64 -o test.cgi cgi.asm

results:

Code:

| => nasm -f macho64 -o test.cgi cgi.asm
/* no output */
| => ./test.cgi
-bash: ./test.cgi: cannot execute binary file

| => file test.cgi
test.cgi: Mach-O 64-bit object x86_64

This is for Mac OS X:

Code:

| => uname -a
Darwin SpocksBrain 17.0.0 Darwin Kernel Version 17.0.0: Tue Jun 13 21:06:15 PDT 2017; root:xnu-4481.0.0.1.1~1/RELEASE_X86_64 x86_64

LOL I can almost run it this way, but it's in reverse order:

Code:

| => strings test.cgi
Hello world!
Content-type: text/html

The source code explicitly says "ELF entry point" but this is Mach-O. If I tried it on Solaris that uses ELF format binaries, it'd probably work fine.

Laserbeak · 07-07-2017, 05:19 PM

I compiled it in Solaris:

Code:

root@sunshine:~# uname -a
SunOS sunshine 5.11 11.3 i86pc i386 i86pc

Code:

root@sunshine:~# nasm -f elf64 -o test.cgi test.asm

Code:

root@sunshine:~# ./test.cgi
bash: ./test.cgi: Invalid argument

???

NevemTeve · 07-07-2017, 10:49 PM

I would try link it:

Code:

nasm -f elf64 -o test.o test.asm
ld -o test.cgi test.o

Laserbeak · 07-07-2017, 11:34 PM

Quote:

Originally Posted by NevemTeve

I would try link it:

Code:

nasm -f elf64 -o test.o test.asm
ld -o test.cgi test.o

This did work as far as I came up with an executable but it ran and didn't print anything out at all and I just returned to the prompt. Perhaps it went to some log somewhere?

It did not work for Mac OS X replacing -f elf64 with -f macho64 though

NevemTeve · 07-08-2017, 03:14 AM

Works for me:

Code:

uname -mr
3.16.0-4-amd64 x86_64
nasm -f elf64 -o rb_cgi.o rb_cgi.asm
ld -o rb_cgi.cgi rb_cgi.o
./rb_cgi.cgi
Content-type: text/html

Hello world!
file rb_cgi.*
rb_cgi.asm: ASCII text
rb_cgi.cgi: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
rb_cgi.o:   ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

rblampain · 07-13-2017, 12:17 AM

Quote:

How did you try to assemble it? What command did you use?

Code:

nasm -f elf64 test.asm  -o test.o
ld  test.o -o test
<form... action="cgi-bin/test">
<input type="submit" ..>

I did not try to add any extension in the linker command but in theory, the server does not need one. "document root" and "cgi-bin" directories have been left as per original default Debian 7 (no need for added "exec .extension" or "alias .." since whatever is in that directory is considered by Apache2 to be cgi executable)

This code does not call the server and also work in my case

Quote:

uname -mr
3.16.0-4-amd64 x86_64
nasm -f elf64 -o rb_cgi.o rb_cgi.asm
ld -o rb_cgi.cgi rb_cgi.o
./rb_cgi.cgi
Content-type: text/html

but the funny thing is that, calling the server through html submit, itdoes not work in C either even though gcc has no complaint about the source code, doing the same thing in "YABASIC" with two "print" statements in the code (one to screen and the other to file) does not print correctly to the screen (possibly not at all, I cannot remember) altough printing to file shows the correct output (6 'variable name=value' blocks), not code. So it apears that the garbage printed is not code but the correct output (always proportional to the string used) that for some reason Apache2 cannot render correctly. Since the browser is UTF-8 by default which YASM does not understand (although the data is temporarily ASCII only), perhaps, not printing to screen in YABASIC had to be expected so I did not worry too much about that.
I have used verbatim a more involved example from the NCSA (32bit) and it does not work either - same result.

NevemTeve · 07-13-2017, 02:37 AM

Works for me:

Code:

$ ls -l /usr/local/www/cgi-bin/rb_cgi
-rwxr-xr-x 1 projects devel 1096 Jul  8 10:11 /usr/local/www/cgi-bin/rb_cgi

$ file /usr/local/www/cgi-bin/rb_cgi
/usr/local/www/cgi-bin/rb_cgi: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped

$ wget -S -O cgiout http://127.0.0.1:/cgi-bin/rb_cgi
--2017-07-13 10:46:16--  http://127.0.0.1/cgi-bin/rb_cgi
Connecting to 127.0.0.1:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Thu, 13 Jul 2017 08:46:16 GMT
  Server: Apache/2.4.18 (Unix) PHP/7.1.7 OpenSSL/1.0.2l
  Content-Length: 13
  Keep-Alive: timeout=15, max=100
  Connection: Keep-Alive
  Content-Type: text/html
Length: 13 [text/html]
Saving to: 'cgiout'

$ cat cgiout
Hello world!

scasey · 07-13-2017, 01:52 PM

Quote:

Originally Posted by rblampain

I did not try to add any extension in the linker command but in theory, the server does not need one. "document root" and "cgi-bin" directories have been left as per original default Debian 7 (no need for added "exec .extension" or "alias .." since whatever is in that directory is considered by Apache2 to be cgi executable)

I'm sorry, but that is not correct. The server does need an extension which matches one of the values in AddHandler in the httpd.conf file.
Without a matching extension, apache will not execute the script/program, but will just send the contents of the file, which in your case, is a binary file.

Please add a .cgi extension to your compiled file and try again. I don't believe it needs to be re-compiled with the extension, the file just has to have that name for apache to execute it instead of delivering it.

Laserbeak · 07-13-2017, 01:58 PM

I believe if it is in a designated cgi-bin directory the web server should try to execute the file and if that fails for some reason (anything from not being able to execute it at all to returning no header or a bad header) it should just give a server error. It shouldn't send the contents of the file, which means wherever the file was, it wasn't in a properly declared cgi-bin directory.

NevemTeve · 07-13-2017, 02:08 PM

As a last straw, one could check log-files access_log and error_log in directory /var/log/apache2

scasey · 07-13-2017, 05:39 PM

Quote:

Originally Posted by Laserbeak

I believe if it is in a designated cgi-bin directory the web server should try to execute the file and if that fails for some reason (anything from not being able to execute it at all to returning no header or a bad header) it should just give a server error. It shouldn't send the contents of the file, which means wherever the file was, it wasn't in a properly declared cgi-bin directory.

I stand corrected. It appears I've been very lazy and have just been applying the

Code:

Option ExecCGI

directive to directories containing executable scripts rather than creating ScriptAlias for them. When doing that, the

Code:

AddHandler cgi-script .cgi .pl

directive is also required.

When a ScriptAlias directive is defined for a folder, then neither of the other directives are required.

I believe I'll do some tweaking of the config file over the next couple of days. Thank you, Laserbeak and NevemTeve

rblampain, what I've been saying will work, it's just not the only way, and probably not the best way. Please confirm that your cgi-bin does have a ScriptAlias defined for it. Something like:

Code:

ScriptAlias /cgi-bin/ /path/to/the/cgi-bin/

...and I would not expect that to be provided by default,because the realname directory needs to be specified. There may be a default example commented out:

Code:

# ScriptAlias: This controls which directories contain server scripts.
# ScriptAliases are essentially the same as Aliases, except that
# documents in the realname directory are treated as applications and
# run by the server when requested rather than as documents sent to the client.
# The same rules about trailing "/" apply to ScriptAlias directives as to
# Alias.
#
#ScriptAlias /cgi-bin/ "/var/www/cgi-bin"
#
# "/var/www/cgi-bin" should be changed to whatever your ScriptAliased
# CGI directory exists, if you have that configured.

(which I copied from my current httpd.conf -- which is why I need to use the other two directives

rblampain · 07-21-2017, 12:42 AM

I cannot understand what the problem was. Initially having "charset=urf-8" (maybe not the exact spelling) in the header seemed to make it worse, so I took it out on the assumption that I only had ascci in the testing files. In my last test, I put that back and it works and I have no idea what the difference is. There was no need to alter any configuration, as explained in my previous post.