Clicking on a hypertext link while viewing a PDF file shouldn’t be a security problem as long as you trust the viewer it invokes. But users of xpdf version 0.90 discovered that this assumption was an extremely bad one. When an xpdf user clicked on a hypertext link, xpdf started up a viewer (Netscape by default) and sent the URL to the viewer. So far, so good. But the xpdf developers decided to start up the viewer by using the system() call. That was the bad idea..
Calling Components Safely
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Is this really 0.90 ?
We are at 3.xx at the moment.
Is this still an issue?
That’s not the point of the article. The problem was probably fixed long ago.
The point of the article is to help programmers write secure code, and after reading the article I found it very informative and useful. Certainly something every programmer who codes in C should read.
system() and popen(), both of which use subshell invocations rather than spawning new processes, are both hacks. Unfortunately, there is no high level duplicate for these functions that starts processes without an intermediate shell, and you are forced to use execl*()/execv*() manually in conjunction with fork()/waitpid() and possibly pipe() if input/output to the process’s stdin/stdout is needed.
Yet another example of the C library making it difficult to write secure code…
Unfortunately, you still have morons out there touting the advantages of strncpy() over strcpy() when the former can introduce new buffer overflows, and a blind conversion can add new vulnerabilities in instances where even strcpy() is safe. strlcpy() and its ilk are what should be touted, although due to portability reasons I prefer to use a strncpy() wrapper which ensures zero termination…
>Yet another example of the C library making it difficult to write secure code…
Note that one example was with Perl open function being able to execute commands, so C is not the only one..
That said I agree with you, but until glibc maintainers and standard organisation do something we’re stuck: there are already secure libraries for C but as long as they are not available everywhere and standardised, people won’t use them.
Glic maintainers have been especially stupid in non-accepting strl* functions IMHO: it’s a step in the good direction.
Posix is old, very old. It’s too bad it became a de-facto standard, because it should have died long ago.
Posix is old, very old. It’s too bad it became a de-facto standard, because it should have died long ago.
If I read the article correctly, the only Posix specific was “popen”.
Also, Posix is not only a de-facto standard, its a real standard.
POSIX is a very simple, low-level API, that is useful for what it does — provide access to the operating system. Since the operating system contains only low-level functionality (if it is designed properly), this works out nicely. The great tragedy for users of C is that people started to actually use these low-level facilities directly, instead of implementing safer, higher-level constructs on top.
POSIX defines quite a bit more than just system calls.
A lot people think that after reading Andrew Tanenbaum’s book (OS design and imp.), but the think is that he only implements a restricted portion of posix.
A lot people think that after reading Andrew Tanenbaum’s book (OS design and imp.), but the thing is that he only implements a restricted portion of posix.
The author suggests that programs invoking the shell put a backslash
in front of every suspicious character. Unfortunately, in locales
with multibyte characters, it can be hard to tell exactly where the
backslashes should be placed. This is especially true if the attacker
can control environment variables and specify a locale (perhaps even
by file name) that the shell and the calling program parse
differently.
Using single quotes instead of backslashes may be safer, as they will
properly quote multibyte characters even if the shell does not
actually recognize multibyte characters. However, that scheme will
break down too if the encoding (unlike UTF-8) uses the same byte as a
single quote and as part of a multibyte character.
I am not familiar with encodings using shift states but I fear they
will be even worse.