Package: freeradius
Version: 2.1.10
Severity: important
Tags: squeeze sid
There is a buffer overflow bug in radmin program in
freeradius-server (radmin), in conffile.c file.
In function cf_expand_variables, there is a getenv call, and the
env value is copied to a buffer without checking the length of the
buffer.
Malicious attacker can exploit this vulnerability (local exploit) to
either crash the program (DoS) or to hijack the program control.
Example:
Modify the template.conf file from Debian package to have the
following variable:
# just add 1 line below to the beginning of the template.conf
# and rename the template.conf to be radiusd.conf
malicious = $ENV{HOME}
... # other configurations can be the same as the sample
After the modification, we can crash the radmin program by giving a
big env variable such as:
$ HOME=`perl -e 'print "A"x9000'` radmin
sangkilc:~# HOME=`perl -e 'print "A"x9000'` radmin
Segmentation fault
sangkilc:~# HOME=`perl -e 'print "A"x9000'` gdb -q radmin
Reading symbols from /usr/sbin/radmin...(no debugging symbols
found)...done.
(gdb) r
Starting program: /usr/sbin/radmin
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0xb7e67d8d in fgets () from /lib/i686/cmov/libc.so.6
(gdb) q
This is the first report about this bug. The current freeradius repository
still has this bug.
A sample radiusd.conf is attached.
-- System Information:
Debian Release: 6.0.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
# -*- text -*-
##
## templates.conf -- configurations to be used in multiple places
##
## $Id$
######################################################################
#
# Version 2.0 has a useful new feature called "templates".
#
# Use templates by adding a line in radiusd.conf:
#
# $INCLUDE templates.conf
#
# The goal of the templates is to have common configuration located
# in this file, and to list only the *differences* in the individual
# sections. This feature is most useful for sections like "clients"
# or "home_servers", where many may be defined, and each one has
# similar repeated configuration.
#
# Something similar to templates can be done by putting common
# configuration into separate files, and using "$INCLUDE file...",
# but this is more flexible, and simpler to understand. It's also
# cheaper for the server, because "$INCLUDE" makes a copy of the
# configuration for inclusion, and templates are simply referenced.
#
# The templates are defined in the "templates" section, so that they
# do not affect the rest of the server configuration.
#
# A section can reference a template by using "$template name"
#
malicious = $ENV{HOME}
templates {
#
# The contents of the templates section are other
# configuration sections that would normally go into
# the configuration files.
#
#
# This is a default template for the "home_server" section.
# Note that there is no name for the section.
#
# Any configuration item that is valid for a "home_server"
# section is also valid here. When a "home_server" section
# is defined in proxy.conf, this section is referenced as
# the template.
#
# Configuration items that are explicitly listed in a
# "home_server" section of proxy.conf are used in
# preference to the configuration items listed here.
#
# However, if a configuration item is NOT listed in a
# "home_server" section of proxy.conf, then the value here
# is used.
#
# This functionality lets you put common configuration into
# a template, and to put only the unique configuration
# items in "proxy.conf". Each section in proxy.conf can
# then contain a line "$template home_server", which will
# cause it to reference this template.
#
home_server {
response_window = 20
zombie_period = 40
revive_interval = 120
#
# Etc.
}
#
# You can also have named templates. For example, if you
# are proxying to 3 different home servers all at the same
# site, with identical configurations (other than IP
# addresses), you can use this named template.
#
# Then, each "home_server" section in "proxy.conf" would
# only list the IP address of that home server, and a
# line saying
#
# $template example_com
#
# That would tell FreeRADIUS to look in the section below
# for the rest of the configuration items.
#
# For various reasons, you shouldn't have a "." in the template
# name. Doing so means that the server will be unable to find
# the template.
#
example_com {
type = auth
port = 1812
secret = testing123
response_window = 20
#
# Etc...
}
#
# You can have templates for other sections, too, but they
# seem to be most useful for home_servers.
#
# For now, you can use templates only for sections in
# radiusd.conf, not sub-sections. So you still have to use
# the "$INCLUDE file.." method for things like defining
# multiple "sql" modules, each with similar configuration.
#
}
# -*- text -*-
##
## templates.conf -- configurations to be used in multiple places
##
## $Id$
######################################################################
#
# Version 2.0 has a useful new feature called "templates".
#
# Use templates by adding a line in radiusd.conf:
#
# $INCLUDE templates.conf
#
# The goal of the templates is to have common configuration located
# in this file, and to list only the *differences* in the individual
# sections. This feature is most useful for sections like "clients"
# or "home_servers", where many may be defined, and each one has
# similar repeated configuration.
#
# Something similar to templates can be done by putting common
# configuration into separate files, and using "$INCLUDE file...",
# but this is more flexible, and simpler to understand. It's also
# cheaper for the server, because "$INCLUDE" makes a copy of the
# configuration for inclusion, and templates are simply referenced.
#
# The templates are defined in the "templates" section, so that they
# do not affect the rest of the server configuration.
#
# A section can reference a template by using "$template name"
#
malicious = $ENV{HOME}
templates {
#
# The contents of the templates section are other
# configuration sections that would normally go into
# the configuration files.
#
#
# This is a default template for the "home_server" section.
# Note that there is no name for the section.
#
# Any configuration item that is valid for a "home_server"
# section is also valid here. When a "home_server" section
# is defined in proxy.conf, this section is referenced as
# the template.
#
# Configuration items that are explicitly listed in a
# "home_server" section of proxy.conf are used in
# preference to the configuration items listed here.
#
# However, if a configuration item is NOT listed in a
# "home_server" section of proxy.conf, then the value here
# is used.
#
# This functionality lets you put common configuration into
# a template, and to put only the unique configuration
# items in "proxy.conf". Each section in proxy.conf can
# then contain a line "$template home_server", which will
# cause it to reference this template.
#
home_server {
response_window = 20
zombie_period = 40
revive_interval = 120
#
# Etc.
}
#
# You can also have named templates. For example, if you
# are proxying to 3 different home servers all at the same
# site, with identical configurations (other than IP
# addresses), you can use this named template.
#
# Then, each "home_server" section in "proxy.conf" would
# only list the IP address of that home server, and a
# line saying
#
# $template example_com
#
# That would tell FreeRADIUS to look in the section below
# for the rest of the configuration items.
#
# For various reasons, you shouldn't have a "." in the template
# name. Doing so means that the server will be unable to find
# the template.
#
example_com {
type = auth
port = 1812
secret = testing123
response_window = 20
#
# Etc...
}
#
# You can have templates for other sections, too, but they
# seem to be most useful for home_servers.
#
# For now, you can use templates only for sections in
# radiusd.conf, not sub-sections. So you still have to use
# the "$INCLUDE file.." method for things like defining
# multiple "sql" modules, each with similar configuration.
#
}
