security report

[Tomasz Kłoczko]

On Mon, 27 May 2002, Blues wrote:

> Wybrane rzeczy - hurtem. Sendmail jest u nas do poprawki - reszta rzeczy 
> nie wiem.
> Prosiłbym o zwrócenie na to uwagi priorytetowo.
> 
> 5. Sendmail
> 
>     Vendor: Sendmail Consortium
> 
>     A denial of service vulnerability was reported in sendmail.  A
>     local user can use file locking mechanisms on critical sendmail
>     files to deny service to all sendmail users.
> 
>     Impact: Denial of service via local system
> 
>     Alert: http://securitytracker.com/alerts/2002/May/1004368.html

"Solution:  As long as a user can not open a file, the user cannot use 
either flock() or fcntl() to lock the file. So, a workaround is to protect 
all files that are locked by sendmail such that the files cannot be opened 
by untrusted users. Because sendmail queue files should already have 
restricted permissions, it is reported that the critical sendmail files 
that should be protected are the alias, map, statistics, and pid files. 
These files should be configured to be owned by either root or by the 
trusted user specified in the TrustedUser option. Change the permissions 
on these files to be readable and writable by only that user, as shown in 
the following examples (these examples are path dependant):

chmod 0640 /etc/mail/aliases /etc/mail/aliases.{db,pag,dir}
chmod 0640 /etc/mail/*.{db,pag,dir}
chmod 0640 /etc/mail/statistics /var/log/sendmail.st
chmod 0600 /var/run/sendmail.pid /etc/mail/sendmail.pid

Note that if /var/run/ directory is cleared on reboots (thereby erasing 
the sendmail.pid file), you must add a chmod command for the pid file in 
the sendmail startup script to be executed after sendmail is started. 
Otherwise, the pid file will have insecure permissions.

If the permissions 0640 (group readable) are used on any of these files, 
ensure that only trusted users belong to the group assigned to those 
files. Otherwise, ensure that the files are not group readable.

According to the report, sendmail 8.12.4 will change the default 
permissions for newly created map and alias database files to mode 0640, 
the installation process will create the statistics file with mode 0600 if 
it does not already exist, and the pid file will be created with mode 
0600. A future version of sendmail will reportedly introduce a feature to 
limit the amount of time spent waiting for a file lock to avoid denial of 
service conditions.

To determine what processes are holding locks on your system, use a tool 
that reads process file descriptor tables, such as lsof, available from:

ftp://vic.cc.purdue.edu/pub/tools /unix/lsof/

With lsof, you can find the process or processes holding a shared or 
exclusive lock on a file as follows:
# lsof /etc/settings
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
lockit 25472 badguy 3rW VREG 116,131072 1841 292 /etc/settings

In the above lsof example, user 'badguy' has a process named 'lockit' (pid 
25472) that has the '/etc/settings' file opened for reading ('r') and has 
obtained an exclusive write ('W') lock as shown in the FD column. If this 
condition was due to a malicious user, the system administrator could kill 
the offending process to drop the lock."

Nie wiem czy to przypadkiem nie zablokuje uzywania sendmaila lokalnie dla
użytkowników.
Wypadałoby żeby ktoś to sprawdził.


> 22. Ethereal
>     Vendor: Ethereal.com 
>     Several potential vulnerabilities have been reported in the
>     Ethereal network sniffer.  A remote user could cause the sniffer to
>     crash or possibly execute arbitrary code.
> 
>     Impact: Denial of service via network
> 
>     Alert: http://securitytracker.com/alerts/2002/May/1004344.html

Tu już jest poprawiaone. Mamy wersje 0.9.4 która juz tego nie ma.


> 23. Fetchmail
> 
>     Vendor: Raymond, Eric S.
> 
>     A buffer overflow vulnerability was reported in 'fetchmail'.  A
>     malicious remote server could cause arbitrary code to be executed
>     on the system running 'fetchmail'.
> 
>     Impact: Denial of service via network
> 
>     Alert: http://securitytracker.com/alerts/2002/May/1004342.html

"Solution:  No solution was available at the time of this entry."

> 26. Talkd
> 
>     Vendor: [Multiple Authors/Vendors]
> 
>     A format string vulnerability was reported in many
>     implementations of 'talkd'.  A remote user may be able to cause
>     'talkd' to execute arbitrary code with root privileges.
> 
>     Impact: Execution of arbitrary code via network
> 
>     Alert: http://securitytracker.com/alerts/2002/May/1004339.html

"Solution:  No solution was available at the time of this entry."

> 34. Bzip2
> 
>     Vendor: [Multiple Authors/Vendors]
> 
>     A symbolic link (symlink) hole was reported in the 'bzip2' file
>     compression utility.  A local user may be able to read files with
>     elevated privileges.
> 
>     Impact: Disclosure of system information
> 
>     Alert: http://securitytracker.com/alerts/2002/May/1004330.html

"Solution:  The vendor has released a fixed version (1.0.2)"
Czyli mamy już to dawno poprawione.


> 35. K5su
> 
>     Vendor: [Multiple Authors/Vendors]
> 
>     A potential vulnerability was reported in the 'k5su' utility
>     when run on FreeBSD and possibly other BSD-based operating systems.
>     A local user that is not in the 'wheel' user group may access the
>     utility.
> 
>     Impact: User access via local system
> 
>     Alert: http://securitytracker.com/alerts/2002/May/1004329.html

Nie mamy na razie k5su.


> 36. ViewCVS
> 
>     Vendor: Viewcvs.sourceforge.net
> 
>     A vulnerability was reported in the ViewCVS web-based CVS
>     interface software.  A remote user can conduct cross-site scripting
>     attacks against ViewCVS users to steal their authentication cookies.
> 
>     Impact: Disclosure of authentication information
> 
>     Alert: http://securitytracker.com/alerts/2002/May/1004328.html

Nie mamy na razie tego pakietu.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*