[Openswan dev] shrewsoft <-> openswan not working with PSK+XAUTH

_______________________________________________
Dev mailing list
Dev <at> openswan.org
http://lists.openswan.org/mailman/listinfo/dev

[Openswan dev] Makefile gcc to $(GCC) patch

The following files in openswan 2.5.17 have a static "gcc" instead of "$(GCC) in the make lines :

lib/Makefile.library
lib/libopenswan/Makefile
lib/libwhack/Makefile
programs/Makefile.program
programs/pluto/tpm/Makefile
programs/pluto/Makefile
programs/pluto/Makefile.options

Patch is attached.

Thanks,

-Brian T.

_______________________________________________
Dev mailing list
Dev <at> openswan.org
http://lists.openswan.org/mailman/listinfo/dev

Re: [Openswan dev] [Openswan Users] FATAL ERROR: unable to malloc 0 bytes for state array

On Mon, 12 May 2008, Ming-Ching Tiew wrote:

Thanks for the malloc pointer and the the pluto leak logs.

> Subject: Re: [Openswan Users] FATAL ERROR: unable to malloc 0 bytes for state
>     array

> By the way, I have confirmed that change uclibc GLIBC_COMPATIBILITY ( ie to allow malloc(0) to succeeed )
indeed fixes the problem.

Does uclibc needs to be recompiled with GLIBC_COMPATIBILITY, or did you need to define it
within Openswan to make it work?

Still malloc(0) makes no sense. Do you know where in the code this malloc() was happening?

> There is an (old) internet thread about someone has posted a patch for freeswan on this issue.

A google for GLIBC_COMPATIBILITY gives me 0 results....

As for the leaks, your logs show:

leak: self-vendor ID
leak: myid string
leak: my FQDN
leak: esp string
leak: struct event in event_schedule()
leak: myid string
leak: pluto helpers
leak: 2 * struct event in event_schedule()
leak: ocspcerts path
leak: aacerts path
leak: certs path
leak: private path
leak: crls path
leak: cacert path
leak: acert path

Of these, struct event in event_schedule() is the most interesting, as it will occur
regularly. The others are mostly a one-time use (except "esp string" which was fixed
already in cvs/git)

This seems to be bug 652, see http://bugs.xelerance.com/view.php?id=652

I see an alloc_thing of struct event, and no associating free call. I am not
entirely sure where this is supposed to be freed.

Paul
--

-- 
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

[Openswan dev] openswan-2.6.13: use of unset pointer variables

I'm not being too careful, so I may be wrong.  I've just bean glancing at 
the code.

In programs/pluto/spdb_print.c function print_sa_attr_oakley the variable 
"en" may not be initialized when it is used.

The obvious fix is to initialize it to NULL in its declaration.

The same bug appears in print_sa_attr_ipsec.

The same bug appears in print_sa_v2_trans.

print_sa_v2_attr looks like it should be fixed up so that it can have
the bug .  But I haven't looked at it carefully.

I've not compiled the code but I would have thought that gcc, with
appropriate flags, would have warned about these bugs.  Am I wrong?

Are other gcc-diagnosable problems being ignored?  Are more -W flags 
needed?

[Openswan dev] a little nit picking about openswan-2.6.13

In include/packet.h's definition of struct ikev2_trans_attr, the last line 
is a comment:
        /* u_int16_t isatr_value;      Value (AF=0) or not transmitted (AF=1) */

On the assumption that these are Oakley-style attributes, this comment is 
misleading and wrong.

- if a value field like this is present, it is only present if AF=0 so
  the comment on the comment is misleading.

- if a value field is present, it would not be constrained to be an 
  u_int_16_t.  It would be a sequence of bytes with a length indicated
  by the value of isatr_lv.  And the bytes would be in network order (I 
  think), not host order.

- I think I heard that AF=0 never happens in IKEv2 (I don't know).  If so
  the comment is pointless.

================================================================
In include/pluto_constants.h:

#define IS_PARENT_SA(st) ((st)->st_clonedfrom == SOS_NOBODY)
#define IS_CHILD_SA(st)  ((st)->st_clonedfrom != SOS_NOBODY)

Are all states either a parent or a child and never both?

The second definition could be:
  #define IS_CHILD_SA(st)  (!IS_PARENT_SA(st))
This would be more robust because there would be less duplicated code
to diverge.

================================================================

In lib/libopenswan/alg_info.c:

To my eyes, aalg_getbyname_esp's gotos are ugly and unnecessary.

The use of INT_MAX is scary: couldn't we give this designator a
meaningful name (and value) along with all the other values this
variable can take?

Does the function really return an int or is it actually some (perhaps
extended) enum type?

I don't really understand the scanf -- I never use that scary
function.  Should the return value not be tested?  The test after it
looks as if && should be ||, but I don't understand it well enough to
be sure.

modp_getbyname_esp is simpler but its goto is also gratuitous.  This
looks clearer to me:

{
	int ret = -1;

	if (str != NULL && *str != '\0') {
		ret = alg_enum_search_prefix(&oakley_group_names, "OAKLEY_GROUP_", str,len);
		if (ret < 0)
			ret = alg_enum_search_ppfix(&oakley_group_names, "OAKLEY_GROUP_", " (extension)", str, len);
	}
	return ret;
}

================================================================

In programs/pluto/ikev2.c near line 292:

It looks as if a packet that has both I and R flags, or neither, is
accepted.  Is this reasonable?

================================================================

The comments in programs/pluto/ikev2_crypto.c line 107 are scary.

================================================================

programs/pluto/spdb_struct.c line 206:

I think that it is generally good style to use braces on neither or
both legs of an if.  Using it on one and not the other is correct but
less clear.

[Openswan dev] Openswan and Debian OpenSSL vulnerability

According to this page, http://wiki.debian.org/SSLkeys, both Openswan and 
StrongSWAN are vulnerable to the Debian OpenSSL vulnerability.

Could someone comment on the extent of this vulnerability?

Re: [Openswan dev] Openswan and Debian OpenSSL vulnerability

On Sun, 2008-05-18 at 11:21 -0400, D. Hugh Redelmeier wrote:
> According to this page, http://wiki.debian.org/SSLkeys, both Openswan and 
> StrongSWAN are vulnerable to the Debian OpenSSL vulnerability.

> Could someone comment on the extent of this vulnerability?

	If you are using X.509 certificates and those certificates were created
on a Debian Etch system, or a distribution based on Debian Etch, you've
probably got an easily guessable private key.  You should use their tool
to scan all your SSL certificates to make sure none are on the "black
list" of bad keys.  Regenerate and recertify any questionable keys and
certificates.  This affects systems other that Debian if the keys were
generated on an affected Debian system and imported onto another.  Weak
keys would allow for the possibility of a man-in-the-middle attack.
With session keys and perfect forward secrecy, you're probably still
safe from sniffing attacks and session cracking, but I wouldn't risk it.

	There is now a rainbow table out of various bad keys and combinations
up at the Metasploit site:

	http://metasploit.com/users/hdm/tools/debian-openssl/

	The key table is in the for of ssh private/public keypairs but it can
be used by attackers against SSL X.509 certs.

	Mike
--

-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw <at> WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

_______________________________________________
Dev mailing list
Dev <at> openswan.org
http://lists.openswan.org/mailman/listinfo/dev

Re: [Openswan dev] Openswan and Debian OpenSSL vulnerability

On Sun, 18 May 2008, D. Hugh Redelmeier wrote:

> According to this page, http://wiki.debian.org/SSLkeys, both Openswan and
> StrongSWAN are vulnerable to the Debian OpenSSL vulnerability.

Only X.509 keys generated using openssl on Debian. Raw RSA host keys
generated on debian systems by Openswan are fine. Openswan does not
use openssl code anywhere (except openswan 3.x uses some, but not for
generating long term keys).

Paul
--

-- 
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

Re: [Openswan dev] openswan-2.6.13: use of unset pointer variables

On Sun, 18 May 2008, D. Hugh Redelmeier wrote:

> In programs/pluto/spdb_print.c function print_sa_attr_oakley the variable
> "en" may not be initialized when it is used.

I've fixed these. Thanks.

> print_sa_v2_attr looks like it should be fixed up so that it can have
> the bug .  But I haven't looked at it carefully.

I have not changed this one yet.

> I've not compiled the code but I would have thought that gcc, with
> appropriate flags, would have warned about these bugs.  Am I wrong?

It did not generate warnings with my gcc.

> Are other gcc-diagnosable problems being ignored?  Are more -W flags
> needed?

Nothing is being ignored on purpose.

Paul
--

-- 
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

Re: [Openswan dev] a little nit picking about openswan-2.6.13

On Sun, 18 May 2008, D. Hugh Redelmeier wrote:

> In include/packet.h's definition of struct ikev2_trans_attr, the last line
> is a comment:
>         /* u_int16_t isatr_value;      Value (AF=0) or not transmitted (AF=1) */
>
> On the assumption that these are Oakley-style attributes, this comment is
> misleading and wrong.
>
> - if a value field like this is present, it is only present if AF=0 so
>   the comment on the comment is misleading.

The comment in the comment says "aif AF=0 then value, if AF=1 then not present"

> - if a value field is present, it would not be constrained to be an
>   u_int_16_t.

That's true. I was not sure what to put in here, since the length has no
set boundary. The u_int16_t made it a multiple of 4.

I've changed the comment to:

        /* u_intXX_t isatr_value;      Value if AF=0, absent if AF=1 */

> - I think I heard that AF=0 never happens in IKEv2 (I don't know).  If so
>   the comment is pointless.

So far IKEv2 does not specify an option using this mechanism, but it does
specify this mechanism, which would be valid for private use options that
need to transfer a value larger then u_int_16_t (of the lv field when AF=0)

> ================================================================
> In include/pluto_constants.h:
>
> #define IS_PARENT_SA(st) ((st)->st_clonedfrom == SOS_NOBODY)
> #define IS_CHILD_SA(st)  ((st)->st_clonedfrom != SOS_NOBODY)
>
> Are all states either a parent or a child and never both?

Yes.

> The second definition could be:
>   #define IS_CHILD_SA(st)  (!IS_PARENT_SA(st))
> This would be more robust because there would be less duplicated code
> to diverge.

I have made this change,

Paul