Code one C Instrukcja Użytkownika Pobierz pdf (Strona 10)

An option in the Apache web server httpd lets the server

execute CGI programs as the program owner (e.g. using

the owner’s user ID and group ID). Since httpd runs as the

user apache, it cannot run any program as another user, so

it asks suexec to do it. This option, however, is turned off

by default, therefore by default httpd executes CGI pro-

grams as the user apache. To prevent non-root users from

running suexec directly, suexec is executable by the user

root and the group apache but not by anyone else.

However, a local adversary on the web server can cir-

cumvent this protection by running suexec from his CGI

program because the CGI program runs as the group

apache and so can run suexec. This seems very dangerous

because now the adversary can run any program as any

user. Fortunately, to ensure that it will not do any harm

to the system, suexec performs many security checks, in-

cluding:

• It checks that the current directory is within DOC-

ROOT (e.g. public

html/cgi-bin).

• It checks that the requested user and group IDs own

the current directory.

• It checks that the requested user and group IDs own

the requested program.

• It checks that the last component in the path to the

requested program is not a symbolic link. (However,

it does not check if a directory name in the path is a

symbolic link.)

• It checks that the command does not start with / or

../ and does not contain /../, to prevent the com-

mand from escaping DOCROOT.

Notwithstanding these paranoid checks, the adversary

can still attack the system in at least the following two

cases:

• For any target user on the system, the adversary can

execute any program that is owned by the victim and

is in a subdirectory of the victim’s CGI directory.

This may not seem a risk because the victim should

assume that any program under his CGI directory can

be invoked at any time by a web user. However, the

threat is that this may break the victim’s expectations

in two different ways, as listed below, and this could

lead to a security violation.

– First, the victim can no longer prevent other

users from executing the programs in his CGI

directory by setting ﬁle permission appropri-

ately. For example, when the victim is exper-

imenting with a CGI program that has not been

audited for security, he may want to prevent

other users from running the program by set-

ting the ﬁle not world executable, but he might

not realize that an adversary can still run his

program via suexec.

– Second, the victim can no longer expect the

command line arguments to his CGI program

to come from the web server and therefore to

be well-formed, because the adversary can pass

arbitrary arguments to the CGI program via

suexec. As the victim may not expect this, he

may not have written his CGI programs to de-

fend against malicious data in command line ar-

guments.

This becomes more serious if the victim creates a

symbolic link from his CGI directory to his home

directory, as now the adversary can run every pro-

gram in his home directory with command line ar-

guments of his choice, and these programs runs with

the victim’s privileges. This may allow the adversary

to gain control of the victim’s account.

• On systems where a non-root user can change the

ownership of his ﬁles, such as some systems derived

from System V Unix, the attack becomes more se-

vere. The adversary can create a directory within his

DOCROOT, create a malicious programinside it, and

change the ownership of both to the victim. Then the

adversary lets suexec (via his CGI program) to run

the malicious program as the victim.

Discovering both these security issues in suexec re-

quired some manual analysis, but MOPS pointed us to

the right place to start and helped ﬁnd “the needle in the

haystack”. This example shows the value of looking for

suspicious code, even when that code is not previously

known for certain to be a security hole.

4.2. Standard File Descriptor Vulnerabilities

at in At at is a setuid-root program. It reads the com-

mands that the user wants to execute at a certain time from

the standard input and writes them into a ﬁle. Later, the

daemon atd executes the ﬁle. The ﬁle is placed in a direc-

tory that ordinary users cannot read from or write to.

at does not take care to ensure that the ﬁrst three ﬁle

descriptors are open before it opens any ﬁle for writing.

Because the invoker controls the initial bindings of all ﬁle

descriptors, an adversary can cause at to open a ﬁle in

writing mode to stderr. For example, the adversary could

close stdout and stderr and then invoke at. at ﬁrst opens a

lock ﬁle, which will be assigned to stdout, and then opens

a task ﬁle to record the user’s commands, which will be

assigned to stderr. From now on, all messages for stderr

will enter the task ﬁle.

1 2 ... 5 6 7 8 9 10 11 12 13 14 15

Komentarze do niniejszej Instrukcji

Brak uwag

Code one C Instrukcja Użytkownika Strona 10

Komentarze do niniejszej Instrukcji

Powiązane produkty i podręczniki dla Wykrywacze dymu Code one C