Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 19 Sep 2012 20:29:50 -0600
From: Kurt Seifried <>
CC: Jan Lieskovsky <>,
        "Steven M. Christey" <>,
        Damien Stuart <>, Michael Rash <>
Subject: Re: CVE Request -- fwknop 2.0.3: Multiple security

Hash: SHA1

On 09/19/2012 12:10 PM, Jan Lieskovsky wrote:
> Hello Kurt, Steve, vendors,
> multiple securit issues have been corrected in 2.0.3 upstream
> version of fwknop
> (
> 1) multiple DoS / code execution flaws: Upstream patch: [1]

yeah this seems to be mostly changes related to char buf[32] to
char buf[ACCESS_BUF_LEN], plus some logic cleanups (like making sure
the port specified is larger than 0 and less than MAX_PORT). So I'll
lump them all together rather than separate them.

Please use CVE-2012-4434 for this issue.

> 2) server did not properly validate allow IP addresses from
> malicious authenticated clients Upstream patch: [2]

question possibly (didn't look at the code apart from the fix).
I see:

if(char_ctr >= MAX_IPV4_STR_LEN)

but nothing for IPv6 (does fwknopd even support ipv6?)... someone may
want to check that.

Please use CVE-2012-4435for this issue.

> 3) strict filesystem permissions for various fwknop files are not
> verified

This seems more like security hardening. Generally speaking network
daemons are not responsible for ensuring the safety of their own files
(the system should have a sane configuration). Also if I assign a CVE
for this then every single daemon that creates a config file and fails
to check the permissions qualifies for a CVE that's a few hundred
thousand CVEs =). For example: OpenSSH, it has a number of checks on
file permissions, no CVE's for that.

> 4) local buffer overflow in --last processing with a maliciously
> constructed ~/ file Upstream patch: [3]

is the MAX_CMDLINE_ARGS stuff specifically I assume?

Please use CVE-2012-4436 for this issue.

> For the remaining ones: ======================= 5) several
> conditions in which the server did not properly throw out
> maliciously constructed variables in the access.conf file Upstream
> patch: [4]
>  Note: This doesn't look like a security flaw (previously possible
> to provide malicious values to access.conf file, but I assume it
> would required administrator privileges).
> 6) [test suite] Added a new fuzzing capability to ensure proper
> server-side input validation. Note: Test-suite add-on, no CVE
> needed.
> 7) Fixed RPM builds by including the $(DESTDIR) prefix for
> uninstall-local and install-exec-hook stages in 
> Upstream patch: [5]
>  Note: Also doesn't look like a fix for a security flaw.
> Could you allocate CVE ids for issues 1), 2), 3), and 4) ?
> [Cc-ed Damien and Michael from fwknop upstream to confirm they {the
> first four} should receive a CVE identifier].
> Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat
> Security Response Team

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ