Follow @Openwall on Twitter for new release announcements and other news
[<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

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.