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 19:11:08 -0600
From: Kurt Seifried <>
CC: Michael Rash <>, Jan Lieskovsky <>,
        "Steven M. Christey" <>,
        Damien Stuart <>
Subject: Re: Re: CVE Request -- fwknop 2.0.3: Multiple security

Hash: SHA1

On 09/19/2012 03:26 PM, Michael Rash wrote:
> On Sep 19, 2012, 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]
2) server did not properly validate allow IP addresses from malicious
>> authenticated clients Upstream patch: [2]
3) strict filesystem permissions for various fwknop files are not verified
>> 4) local buffer overflow in --last processing with a maliciously
>> constructed ~/ file Upstream patch: [3]
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].
> I would say that the first four should receive CVE identifiers,
> yes. For 5), it could be a security issue in older versions of
> fwknop if the umask at install time was permissive enough to allow
> non-admin users to modify the access.conf file, but this is
> unlikely I think so probably doesn't deserve a CVE identifier.

I will be doing the CVE assignments in a bit (need to check up on
these) but as far as access to config files due to bad umask, that's a
configuration problem that doesn't deserve a CVE in this instance (and
in most instances).

> Thanks,

- -- 
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.