netdev - Re: [SECURITY] CAN info leak/minor heap overflow

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:	Tue, 02 Nov 2010 20:43:16 +0100
From:	Oliver Hartkopp <socketcan@...tkopp.net>
To:	Dan Rosenberg <drosenberg@...curity.com>
CC:	urs.thuermann@...kswagen.de, netdev@...r.kernel.org,
	security@...nel.org
Subject: Re: [SECURITY] CAN info leak/minor heap overflow

Hello Dan,

On 02.11.2010 19:28, Dan Rosenberg wrote:
> In bcm_connect() (in net/can/bcm.c), I noticed the following code:
> 
> 	sprintf(bo->procname, "%p", sock);
> 
> "procname" is a 9-byte char array.  This code is wrong on two levels.
> First, leaking a kernel address via a /proc filename is bad.

Why is this bad? Can the addresses of CAN-BCM sock structs be used for
anything from userspace?

For me they are just intented to be unique numbers ...

> Secondly,
> on 64-bit platforms, up to 17 bytes may be copied into the buffer.

Hm - that's indeed not wanted. Will send a patch at least for this issue.

> Fortunately, structure padding will most likely prevent this from being
> a problem, except for the trailing NULL byte, which may overwrite the
> first byte of the next heap object.  Please name your procfile in a way
> that doesn't leak information and fits into the desired name buffer.
> 
> -Dan
> 

Regards,
Oliver


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