[Pluto-security] Fwd: Problema di sicurezza nel kernel 2.4.18
Tom
dido@sicurweb.com
Sun, 21 Jul 2002 23:05:04 +0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Per conoscenza....
- -------------------------------------------------------------------------
Per tutti coloro che hanno il kernel 2.4.18 :-(
Linux Kernels DoSable by File-max Limit
- ------------------------------------------------------------------------
SUMMARY
A security vulnerability Linux allows normal users (that were not
limited
with the resources they are able to allocate) to exhaust all elevated
privileges related file slots, making the system unusable.
Solution:
No temporary solution yet, there should be a global per user file limit,
the reserved file descriptors should be given out under another uid/euid
policy. The NR_RESERVED_FILES limit seems to be too low.
Solution 2
[presa da una seconda mail, n.d.r.]
risolvi con PAM:
Almost all Linux distributions ship with PAM support making it universally
available. PAM limits provide a single standardized interface to setting user
limits, instead of having to write complex shell configuration files (such as
/etc/profile) you simply edit the "limits.conf" file. As well applying limits
selectively through the command shell is very difficult,
whereas with PAM applying limits globally, on groups or on individual users is
quite simple. Documentation is available on PAM usually in the
"/usr/share/doc/" tree. To enable PAM limits you need to add a line such as:
session required /lib/security/pam_limits.so
to the appropriate Pam configuration file (i.e. /etc/pam.d/sshd). You can then
define limits, typically these are in "/etc/security/limits.conf" or a
similar location. Because most of these limits are enforced by the shell the
system cannot log all violations of limits (i.e. you will be notified in
syslog when a user exceeds the number of times they are allowed to login,
however you will not receive a warning if the user tries to use more disk
space then they are allowed to).
The available limits are:
core -- Limits the core file size (KB); usually set to 0 for most users to
prevent core dumps.
data -- Maximum data size (KB).
fsize -- Maximum file size (KB).
memlock -- Maximum locked-in-memory address space (KB).
nofile -- Maximum number of open files.
rss -- Maximum resident set size (KB).
stack -- Maximum stack size (KB).
cpu -- Maximum CPU time (MIN).
nproc -- Maximum number of processes.
as -- Address space limit.
maxlogins -- Maximum number of logins for this user or group.
priority -- The priority to run user process with.
For example you can limit the amount of memory that user "bob" is allowed to
use:
user hard memlock 4096
This would place a hard (absolute) limit of 4 megabytes on memory usage for
"bob". Limits can be placed on users by listing the user name, groups by
using the syntax "@group" or globally by using "*".
core files can be created when a program crashes. They have been used in
security exploits, overwriting system files, or by containing sensitive
information (such as passwords). You can easily disable core dumps using PAM,
and generally speaking most users will not notice, however if you have
software developers they may complain.
* hard core 0
fsize is generally a good idea to set, many users will have a large filesystem
quota (i.e. tens of megabytes to several hundred or several gigabytes),
however if they are allowed to create a single file that is abnormally large
they can easily hog disk I/O resources (i.e. create a large file and
copy/delete the copy repeatedly). Setting this limit globally can also
prevent an attacker from trying to fill up the partitions your log files are
stored on, for example if you only have a single / partition an attacker can
easily fill it up by generating a lot of log events.
@notroot hard data 102400
Of course limiting CPU time is one of the classic administrative tasks, this
is very useful for preventing run-away processes from eating up all the cpu
time, and it ensures that if a user leaves something running in background
(such as a packet sniffer) it will eventually be killed. Limiting CPU time
will have several side effects however, once of which will be limiting the
amount of time a user can spend logged in (eventually they will run out of
CPU time and the session will be killed), this can lead to problems if users
spend long periods logged in. As well depending on the CPU(s) present in
your machine the limits can vary greatly (one minute on a 386 is quite a bit
different then one minute on a 1.3 GHz Athalon).
@students hard cpu 2
Limiting the number of times a user can login is strongly advised, for most
situations users should not need to log in to a server more then once, and
allowing them to do so let's them use more resources then you might intend.
As well it can be used to detect suspicious activity, if users know they can
only login once then attempts to log in multiple times can be viewed as
suspicious activity (i.e. an attacker with a stolen password trying to access
the account).
@users hard maxlogins 1
Additionally when someone violated this limit it will be logged in syslog:
Apr 15 15:09:26 stench PAM_unix[9993]: (sshd) session opened for user test
by (uid=0)
Apr 15 15:09:32 stench pam_limits[10015]: Too many logins (max 1) for test
Soft limit violations will not be logged (i.e. a soft limit of 1 and a hard
limit of 2).
Bash
Bash has built in limits, accessed via "ulimit". Any hard limits cannot be set
higher, so if you have limits defined in /etc/profile, or in the users
.bash_profile (assuming they cannot edit/delete .bash_profile) you can
enforce limits on users with Bash shells. This is useful for older Linux
distributions that lack PAM support (however this is increasingly rare and
PAM should be used if possible). You must also ensure that the user cannot
change their login shell, if they use "chsh" to change their shell to ksh for
example the next time they login they will have no limits (assuming you
cave not put limits on ksh). Documentation is available on ulimit, log in
using bash and issue:
[root@server /root]# help ulimit
ulimit: ulimit [-SHacdflmnpstuv] [limit]
Ulimit provides control over the resources available to processes
started by the shell, on systems that allow such control. If an
option is given, it is interpreted as follows:
-S use the `soft' resource limit
-H use the `hard' resource limit
-a all current limits are reported
-c the maximum size of core files created
-d the maximum size of a process's data segment
-f the maximum size of files created by the shell
-l the maximum size a process may lock into memory
-m the maximum resident set size
-n the maximum number of open file descriptors
-p the pipe buffer size
-s the maximum stack size
-t the maximum amount of cpu time in seconds
-u the maximum number of user processes
-v the size of virtual memory
If LIMIT is given, it is the new value of the specified resource.
Otherwise, the current value of the specified resource is printed.
If no option is given, then -f is assumed. Values are in 1024-byte
increments, except for -t, which is in seconds, -p, which is in
increments of 512 bytes, and -u, which is an unscaled number of
processes.
To disallow core files (by setting the maximum size to 0) for example you
would add:
ulimit -Hc 0
To set limits globally you would need to edit "/etc/profile", of course this
will also affect root, so be careful! To set limits on groups you would need
to add scripting to "/etc/profile" that would check for the user's membership
in a group and then apply the statements, however doing this with PAM is
recommended as it is a lot simpler.
- --
- -------------------------------------
Dido
PGP Public Key
http://web.tiscali.it/di_do/dido.asc
- -------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD4DBQE9Oz4gQe/GGXXd6zQRAjaeAJiPLDw59O8OdwRU/fwYm/SsxKJdAKCGXRUB
BQLnnEph+ZofFzpS2ZztXw==
=20XI
-----END PGP SIGNATURE-----