C [Solved] ELF interpreter /libexec/ld-elf.so.1 not found, error 2 when execl

I'm developing a cgi program in C. I have a jail where run a http server and cgi. Server serves html and other files correctly.
The cgi program executes alone correctly, gives on stdout the correct output, but when I call the cgi from web client, I get "ELF interpreter /libexec/ld-elf.so.1 not found, error 2" error on stdout/stderr.
libexec/ld-elf.so.1 exists and is executable
I compile the cgi app with "clang -o cgi cgi.c" inside the jail. Host and jail are both x86_64 FreeBSD 12.2.

The webserver uses execl(cginame, cginame, (char*)NULL) to call the cgi.

I installed the http server and cgi on host (not jailed) and get the same error.
 
Yes, the webserver calls chroot to restrict to the ~/www/ directory.
What should I do? Disable the chroot call? I don't feel secure doing that because I need to use the port 80.
Can I static link ld-elf.so.1 in my cgi?
 
Yes, the webserver calls chroot to restrict to the ~/www/ directory.
Well, that's why it doesn't find the ld and hence the error.

I never set apache for heavy public use so I'm not the best here to give the advise. My 2c:
Moving to jail is a good start. If it's an apache you could map cgi directory outside of the documentroot. You could/should probably do some testing who is calling that cgi.
You can't use symlink to point outside of the chroot (what would be the point of chroot if that would've worked).
 
What should I do? Disable the chroot call? I don't feel secure doing that because I need to use the port 80.
So, you mean because it needs root privileges for listening? It should drop these privileges anyways, long before your CGI binaries are ever executed.

And then, you said you're running in a jail? What's the point then? An attacker could mess up the jail? If you're worried about that, give it an *exclusive* jail (and probably null-mount the system read-only). And forget about the chroot.

EDIT: if you insist on that chroot, create a statically linked CGI binary ;)
 
Which server? www/apache24?
I installed the http server and cgi on host (not jailed) and get the same error.
Can you run any CGI on server? Try one of these (not in jail)
C:
#include <stdio.h>
int
main(void)
{
        printf("Content-Type: text/plain;charset=us-ascii\n\n");
        printf("TEST\n");
        return 0;
}

Test, and report back.
 
Can you run any CGI on server?
Uhm, I guess you missed part of the thread, the problem is already clear (running in a chroot where the program interpreter is not available).

Static linking is a possible solution, but seriously, I'd just drop the chroot. I don't know what should be the benefit when running inside a jail anyways.
 
  • Thanks
Reactions: a6h
Ok, I have done more testing. The problem is that cgi are inside www chroot directory. As cgi runs on demand it can't link against ld-elf. When compiled with -static, runs without any problem, but size grow up to 600kb after strip, it's manageable size.

If there are no security problems compiling with -static option and running inside a chroot inside a jail I'll follow that route.

Thanks everyone
 
  • Thanks
Reactions: a6h
The possible security problem with static linking is forgetting to recompile after a security issue in a used library was fixed.

On the other hand, I still don't see how the additional chroot would do anything good for security. That's why you use a jail after all.

Further side note: keep in mind that classic CGI requires spawning a new process for each and every request and therefore doesn't scale well. If that could be a problem for your usecase, better use an alternative right away.
 
Yes. An established web server like (like nginx) probably has code reviews, tests, fuzzing in place. Bespoke CGI app? No way.
And also, it doesn't handle sockets etc. Still: No, just no. This is not a question of the programming language you use. Although you probably find a damn lot of braindead broken "web apps" done in PHP.
 
FYI, a web app written in C is already a big security problem.
Depends on what does the cgi do, the environment where it must run and how you develop it. I had problems with web server I didn't used before (althttpd from sqlite.org).

A bad programmed perl/php/javascript/java/whatever language web app, is a big security problem.
 
Back
Top