I looked around for a poc and all I found was this bug report at Redhat where they say they could not make it crash 
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-2199

So in the absence of a poc I restricted testing to confirming tftpd functioned normally for both put and get, and associated commands.

Validated on x86_64

CC: (none) => derekjenn
Whiteboard: (none) => MGA-64-OK

Testing i586

tftp-server appears to be running as root user, it should use an unprivileged user I believe like 'nobody'. Maybe just needs --user=nobody

# ps aux | grep tftp
root     13150  0.0  0.0   2256   584 ?        Ss   10:39   0:00 in.tftpd -s /var/lib/tftpboot


Also although it says in the description that it is a security risk and disabled by default it actually isn't. (The TFTP server is run from /etc/xinetd.d/tftp,
and is disabled by default on a Mageia systems.)

/etc/xinetd.d/tftp

disable	= no

To use 'put' to upload a file it is necessary to chmod 777 /var/lib/tftpboot and add the '-c' option to the server_args in /etc/xinetd.d/tftp

This is a *default* configuration file, meaning it should be adapted to match end user needs. None of the issues reported here can be considered bugs, especially compared to similar xinetd-managed services.

CC: (none) => guillomovitch

I disagree Guillaume.

When an xinetd service says it is a security risk and so is disabled by default and is actually *enabled* by default, that to me is not just a bug but a security hole.

Also it is running as root so what you think to be a disabled security risk is actually an enabled insecure service running as root user.

First, you're wrong. The shipped configuration file has 'disable = yes'.

Second, the package description is way too verbose (that's not supposed to be a usage documentation), and uselessly alarmist (very little security just mean the only kind of access restriction is IP-based). It should rather get trimmed down, rather than taken as an objective security audit.

Third, this has nothing to do with the original security issue involved here. Brining additional concerns just make the update process slower.

Guillaume, we are here to perform QA.

The description actually says the words..

The TFTP server is run from /etc/xinetd.d/tftp, and is disabled by default on a Mageia systems.

This is clearly not the case as demonstrated below..

# ls /etc/xinetd.d/
proftpd-xinetd  rsync  sshd-xinetd  tcpmux  test_server

# urpmi tftp-server
To satisfy dependencies, the following packages are going to be installed:
   Package                        Version      Release       Arch   
(medium "Core Updates")
  xinetd                         2.3.15       1.mga1        x86_64  
(medium "Core Updates Testing")
  tftp-server                    5.0          7.2.mga1      x86_64  
296KB of additional disk space will be used.
138KB of packages will be retrieved.
Proceed with the installation of the 2 packages? (Y/n) y


# cat /etc/xinetd.d/tftp 
# default: off
# description: The tftp server serves files using the trivial file transfer \
#	protocol.  The tftp protocol is often used to boot diskless \
#	workstations, download configuration files to network-aware printers, \
#	and to start the installation process for some operating systems.
service tftp
{
	disable	= no
	socket_type		= dgram
	protocol		= udp
	wait			= yes
	user			= root
	server			= /usr/sbin/in.tftpd
	server_args		= -s /var/lib/tftpboot
	per_source		= 11
	cps				= 100 2
	flags			= IPv4
}

This is mga1 remember.

OK, I was wrong on my first point (I checked in mga2). But my second point still stand: a package description is not a place to describe default package configuration and setup.

We only go by what we see. We don't put it there :P

tftp-5.0-7.3.mga1 available in updates_testing, with trimmed description.

No offence intended but FWIW that was half an hour I had intended to use testing firefox. QA should not have to jump through hoops like this. Please bear that in mind with future updates.

I'm not a native speaker, so I guess this means "thank you for your diligent help on this package for which the original maintainer didn't bothered to answer".

Actually no that wasn't what I meant.

(In reply to comment #12)
> I'm not a native speaker, so I guess this means "thank you for your diligent
> help on this package for which the original maintainer didn't bothered to
> answer".

Well, the original maintainer was away for 5 days, but can continue if you are upset by our wonderful QA ;-)

Thank you Gullaume to take on this update, and thank you Claire to go so deep in the tests. In fact, I think QA should only block an update if the bug reported is not fixed, or a bug was introduced. All other problems found should go to other bug reports, to ensure security fix are pushed as fast as possible.

Status: NEW => ASSIGNED

(In reply to comment #14)
> Thank you Gullaume to take on this update, and thank you Claire to go so deep
> in the tests. In fact, I think QA should only block an update if the bug
> reported is not fixed, or a bug was introduced. All other problems found should
> go to other bug reports, to ensure security fix are pushed as fast as possible.

I sort of agree, but if the bug found can be fixed relatively quickly and the security issue is relatively minor, it's good to just fix it first, so that QA doesn't have to validate two updates for the same package in succession.

As far as the issues Claire raised, I don't think have it enabled by default is an issue, in fact, it should be enabled if you installed it.  The following sounds like a real issue:

"To use 'put' to upload a file it is necessary to chmod 777 /var/lib/tftpboot
and add the '-c' option to the server_args in /etc/xinetd.d/tftp"

Finally, I don't know if tftp can be functional running as a non-root user, but if it can that'd be nice to have.

We can't always test the security hole has been fixed. In these cases we just check for regressions. If something which was wrong before is still wrong it doesn't really make it right. We have to use common sense of course. In this case it seems like something we should be concerned about.

Also in the past we have had problems with creating bugs for issues found and validating the update. Msec adding a require/suggest which wasn't properly configured being a very visible one. The suggest was removed eventually after many complaints but we have found generally that the issues don't get resolved so are reluctant to do so.

According to the man page..

--user username, -u username
    Specify the username which tftpd will run as; the default is "nobody". The user ID, group ID, and (if possible on the platform) the supplementary group IDs will be set to the ones specified in the system permission database for this username.

Seems like just an option in /etc/xinetd.d/tftp

Ours seems to run as root, at least with a 'ps'.

Yes, the "user = root" in /etc/xinetd.d/tftp says it's configured to run as root, and so according to the man page it *can* run as a user, but the question is does this cause some loss in functionality that we need to be concerned about?

Might be risky changing this for an update without knowing the implications, but maybe we can change it in Cauldron and someone can complain if it breaks :o)

(In reply to comment #15)
> "To use 'put' to upload a file it is necessary to chmod 777 /var/lib/tftpboot
> and add the '-c' option to the server_args in /etc/xinetd.d/tftp"
> 

I think we should not default to  allow put : any one will be able to fill up the disks, as trivial ftp means no login needed.

I use tftp to only get, as a net boot server part, and it seems logical to default installing tftp read only, as this is it's main purpose.

Discuting suitable default configuration as part of a security update doesn't bring any additional value for the end user, and just delay the fixed version
availability.

Moreover, selecting a default configuration value is clearly a maintainer responsability, and should be done during development phase, not after the release.

Lastly, that's no point to ask other contributers for help because the QA team is overbooked, if the same team isn't able to focus on its priorities, and make a difference between what is strictly needed now, and what could be eventually done later.

Thatnkyou for your valuable contribution to this Guillaume, it has helped no end.

Testing complete on Mageia 1 i586.

With the default install, the put command fails with "Error code 0: Permission denied", until running "chmod o+w /var/lib/tftpboot", so despite having
/usr/sbin/in.tftpd running as root, there does not appear to be a danger.
I'm guessing it's dropping root privileges.

Could someone from the sysadmin team push the srpm
tftp-5.0-7.3.mga1.src.rpm
from Core Updates Testing to Core Updates.

Advisory: Updated tftp packages fix security vulnerability:

Malicious clients could overflow a buffer in tftpd by specifying a
large value for the utimeout option (CVE-2011-2199).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-2199
http://lists.opensuse.org/opensuse-updates/2011-07/msg00000.html

https://bugs.mageia.org/show_bug.cgi?id=6544

Keywords: (none) => validated_update
CC: (none) => davidwhodgins, sysadmin-bugs
Whiteboard: MGA-64-OK => MGA-64-OK, mga1-32-OK

Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0147

Status: ASSIGNED => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED