netdev - Re: wireless extensions vs. 64-bit architectures

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 12 Mar 2007 10:56:39 -0700
From:	Jean Tourrilhes <jt@....hp.com>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	Jouni Malinen <jkm@...icescape.com>, Michael Buesch <mb@...sch.de>,
	linux-wireless@...r.kernel.org, netdev <netdev@...r.kernel.org>,
	Jeff Garzik <jgarzik@...ox.com>, Dan Williams <dcbw@...hat.com>
Subject: Re: wireless extensions vs. 64-bit architectures

On Sun, Mar 11, 2007 at 06:40:01PM +0100, Johannes Berg wrote:
> On Fri, 2007-03-09 at 13:35 -0800, Jean Tourrilhes wrote:
> 
> > 	It's not as bad as it look like. All userspace programs
> > nowadays use either the iwlib or wpa_supplicant. For example,
> > NetworkManager gets its stuff through wpa_supplicant, and kdenetwork
> > uses iwlib. So, in essence, there is only two places to fix.
> 
> That's definitely not true, the latest network manager I have sources to
> on my laptop right now (0.6.4) uses iwlib but only iw_get_ext and no
> parsing functions.

	You are right. I did assume that if it was using iwlib, it
would use the scan helpers. As I said, I did my audit for the ESSID
stuff and did not refresh for the scan stuff.

> I would guess that others "use" iwlib like that too.

	Which others ? The applications that process scan results can
be counted on your fingers. And if you count the one actively
developped, you can use one hand.

> Can you please also *document* the bandaid and actually *describe* it in
> *words* instead of dense code without comments?

	I did that in the e-mail to Jouni. The problem is that most
people are unfamiliar with decoding iwevents, so can't grasp the
explanation.
	Basically, for iwpoint, we have an outer lenght and an inner
length. If they don't match, we have an alignement issue and just need
to pick the payload 8 bytes after the expected location.
	For other events, they have a well known size. If the outer
lenght is not the expected size, but is expected+4, you just pick the
payload 4 bytes after the expected location.

> I'm still not convinced that papering over the problem in userspace is a
> real solution.

	The final overall solution may be a mix of individual
solutions. This is definitely part of it. We don't know yet what are
the other part of this overall solution.
	This brings a solution to people using current and old
kernel. For example, I would expect to be much easier to convince
distro to update older/stable versions with a new wtool than with a
new kernel. The fix I did is trivial to backport to WT-28 or WT-27
(which I plan to do once it's confirmed it works).

>  johannes

	Have fun...

	Jean

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html