Bug#390035: [Pkg-bluetooth-maintainers] Bug#390035: bluez-utils pin file readable by all

2007-07-09 Thread Mikko Rapeli 
On Sat, Jul 07, 2007 at 07:28:50PM +0200, Filippo Giunchedi wrote:
 On Thu, Oct 19, 2006 at 12:27:14AM +0200, Moritz Muehlenhoff wrote:
  Filippo Giunchedi wrote:
   From what I can tell, when the user reaches the point where he cares 
   about not
   having a default pin he can even change permissions. My rationale being 
   that
   bluetooth is not meant to be used in an hostile environment, moreover the
   security features are rather weak FWIW.
  
  I don't think we need a DSA for this issue.
 
 I agree.
 
 Mikko: the /etc/bluetooth/passkeys dir has been reverted with 3.7-1 and is no
 longer present. Can I close this bug? 

Yes, it's ok.

-Mikko


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#390035: [Pkg-bluetooth-maintainers] Bug#390035: bluez-utils pin file readable by all

2007-07-07 Thread Filippo Giunchedi 
On Thu, Oct 19, 2006 at 12:27:14AM +0200, Moritz Muehlenhoff wrote:
 Filippo Giunchedi wrote:
  From what I can tell, when the user reaches the point where he cares about 
  not
  having a default pin he can even change permissions. My rationale being that
  bluetooth is not meant to be used in an hostile environment, moreover the
  security features are rather weak FWIW.
 
 I don't think we need a DSA for this issue.

I agree.

Mikko: the /etc/bluetooth/passkeys dir has been reverted with 3.7-1 and is no
longer present. Can I close this bug? 

filippo
--
Filippo Giunchedi - http://esaurito.net
PGP key: 0x6B79D401
random quote follows:

What a strange illusion it is to suppose that beauty is goodness.
-- Lev Tolstoj


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#390035: [Pkg-bluetooth-maintainers] Bug#390035: bluez-utils pin file readable by all

2006-10-18 Thread Moritz Muehlenhoff 
Filippo Giunchedi wrote:
 From what I can tell, when the user reaches the point where he cares about not
 having a default pin he can even change permissions. My rationale being that
 bluetooth is not meant to be used in an hostile environment, moreover the
 security features are rather weak FWIW.

I don't think we need a DSA for this issue.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#390035: bluez-utils pin file readable by all

2006-10-09 Thread Mikko Rapeli 
On Mon, Oct 09, 2006 at 12:21:22AM +0200, Moritz Muehlenhoff wrote:
 Mikko Rapeli wrote:
  This small bug affects sarge too so I'm cc'ing security. Attached patches 
  restrict the permissions for sarge and etch/sid so that non-root users can 
  not read the default pin value used in Bluetooth authentication.
 ^
This should have read 'file'.

 I know next to nothing about Bluetooth. What could a malicious user do
 with this pin value and why does it need to be kept secret if it's
 a default value (which I suppose is the same on all Debian installations?)

A default value is much worse than pin file readable by all, but if an adm
changed the pin and would like to keep it secret, then allowing everyone
on the system to read the file by default is not nice. The paranoid adm
should check the pin permissions too, but at least I failed that one for
quite some time. Guess I'm not that paranoid after all... 

If a malicious user knows the pin, he can access the Bluetooth services 
offered by the host from previously unknown Bluetooth addresses. If he also 
can fake Bluetooth addresses and the Debian host allows re-pairing as it
does by default ('pairing multi' in /etc/bluetooth/hcid.conf), then he
can take over existing Bluetooth connections, and even pretend to be the
Debian box for other Bluetooth devices who trust this shared secret and
allow to create new link keys.

In most cases, this is just a minor bug. At least having a default pin
and 'pairing multi' on by default are much bigger issues, but it's a 
security related deviation from upstream. I would like to see this fixed.

-Mikko


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#390035: [Pkg-bluetooth-maintainers] Bug#390035: bluez-utils pin file readable by all

2006-10-09 Thread Filippo Giunchedi 
[CCing upstream]

On Mon, Oct 09, 2006 at 10:27:56AM +0300, Mikko Rapeli wrote:
 On Mon, Oct 09, 2006 at 12:21:22AM +0200, Moritz Muehlenhoff wrote:
  Mikko Rapeli wrote:
   This small bug affects sarge too so I'm cc'ing security. Attached patches 
   restrict the permissions for sarge and etch/sid so that non-root users 
   can 
   not read the default pin value used in Bluetooth authentication.
  ^
 This should have read 'file'.
 
  I know next to nothing about Bluetooth. What could a malicious user do
  with this pin value and why does it need to be kept secret if it's
  a default value (which I suppose is the same on all Debian installations?)
 
 A default value is much worse than pin file readable by all, but if an adm
 changed the pin and would like to keep it secret, then allowing everyone
 on the system to read the file by default is not nice. The paranoid adm
 should check the pin permissions too, but at least I failed that one for
 quite some time. Guess I'm not that paranoid after all... 
 
 If a malicious user knows the pin, he can access the Bluetooth services 
 offered by the host from previously unknown Bluetooth addresses. If he also 
 can fake Bluetooth addresses and the Debian host allows re-pairing as it
 does by default ('pairing multi' in /etc/bluetooth/hcid.conf), then he
 can take over existing Bluetooth connections, and even pretend to be the
 Debian box for other Bluetooth devices who trust this shared secret and
 allow to create new link keys.
 
 In most cases, this is just a minor bug. At least having a default pin
 and 'pairing multi' on by default are much bigger issues, but it's a 
 security related deviation from upstream. I would like to see this fixed.

From what I can tell, when the user reaches the point where he cares about not
having a default pin he can even change permissions. My rationale being that
bluetooth is not meant to be used in an hostile environment, moreover the
security features are rather weak FWIW.
I would like to hear upstream opinion though.

filippo
--
Filippo Giunchedi - http://esaurito.net
PGP key: 0x6B79D401
random quote follows:

At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it on
the computer.
Beware of bugs in the above code; I have only proved it correct, not
tried it.
-- Donald Knuth


signature.asc
Description: Digital signature

Bug#390035: [Pkg-bluetooth-maintainers] Bug#390035: bluez-utils pin file readable by all

2006-10-09 Thread Marcel Holtmann 
Hi Filippo,

  In most cases, this is just a minor bug. At least having a default pin
  and 'pairing multi' on by default are much bigger issues, but it's a 
  security related deviation from upstream. I would like to see this fixed.
 
 From what I can tell, when the user reaches the point where he cares about not
 having a default pin he can even change permissions. My rationale being that
 bluetooth is not meant to be used in an hostile environment, moreover the
 security features are rather weak FWIW.
 I would like to hear upstream opinion though.

starting with bluez-utils-3.7 we are using security user as default
and this means we will always ask the passkey agent. If no agent is
registered, then the connection will be rejected.

Regards

Marcel




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#390035: bluez-utils pin file readable by all

2006-10-08 Thread Moritz Muehlenhoff 
Mikko Rapeli wrote:
 This small bug affects sarge too so I'm cc'ing security. Attached patches 
 restrict the permissions for sarge and etch/sid so that non-root users can 
 not read the default pin value used in Bluetooth authentication.

I know next to nothing about Bluetooth. What could a malicious user do
with this pin value and why does it need to be kept secret if it's
a default value (which I suppose is the same on all Debian installations?)

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#390035: bluez-utils pin file readable by all

2006-09-29 Thread Mikko Rapeli 
This small bug affects sarge too so I'm cc'ing security. Attached patches 
restrict the permissions for sarge and etch/sid so that non-root users can 
not read the default pin value used in Bluetooth authentication.
 
The postinst script was manually tested with fresh installs and upgrades
on both sarge and etch installations.

For the record, both upstream[1] and Fedora[2] have these pin files in
mode 600, so I see no reason for this Debian specific behaviour.

-Mikko

[1]
$ grep -A 1 BlueZ bluez-utils-2.15/hcid/Makefile.am
echo BlueZ  $(DESTDIR)$(pinfile); \
chmod 600 $(DESTDIR)$(pinfile)
[2]
$ rpm2cpio bluez-utils-2.25-12.i386.rpm | cpio -vt | grep bluetooth\/pin
-rw---   1 root root6 Jul 19 22:12 ./etc/bluetooth/pin

diff -u bluez-utils-2.15/debian/bluez-utils.postinst 
bluez-utils-2.15/debian/bluez-utils.postinst
--- bluez-utils-2.15/debian/bluez-utils.postinst
+++ bluez-utils-2.15/debian/bluez-utils.postinst
@@ -3,6 +3,14 @@
 set -e
 case $1 in
 configure)
+   # sarge specific minor security fix:
+   # bluez-utils shipped with /etc/bluetooth/pin readable by 
+   # others so resetting its permissions
+   if [ -e /etc/bluetooth/pin ]  [ 'foo'$( find 
/etc/bluetooth/pin -perm +go=rwx ) != 'foo' ]; then
+   echo Security update: removing group and other 
permissions from file /etc/bluetooth/pin
+   chmod u=rw,go= /etc/bluetooth/pin
+   fi
+
# remove bluez-sdpd init, if present
if [ -f /etc/init.d/bluez-sdp ]; then
/usr/sbin/update-rc.d -f bluez-sdp remove
diff -u bluez-utils-2.15/debian/changelog bluez-utils-2.15/debian/changelog
--- bluez-utils-2.15/debian/changelog
+++ bluez-utils-2.15/debian/changelog
@@ -1,3 +1,9 @@
+bluez-utils (2.15-1.1.0sarge.mcf01) stable-security; urgency=low
+
+  * Try to set tighter /etc/bluetooth/pin permissions
+
+ -- Mikko Rapeli [EMAIL PROTECTED]  Fri, 29 Sep 2006 11:26:08 +0300
+
 bluez-utils (2.15-1.1) stable-security; urgency=high
 
   * Fix command injection insecurity in hcid. See CAN-2005-2547.
diff -u bluez-utils-2.15/debian/rules bluez-utils-2.15/debian/rules
--- bluez-utils-2.15/debian/rules
+++ bluez-utils-2.15/debian/rules
@@ -10,6 +10,8 @@
 
 DEB_CONFIGURE_EXTRA_FLAGS := --enable-pcmcia --enable-dbus --enable-cups 
--enable-hid2hci --enable-bcm203x
 
+DEB_FIXPERMS_EXCLUDE := etc/bluetooth/pin
+
 install/bluez-utils::
# modutils config file
install -D -m 0644 debian/modutils \
@@ -31,6 +33,7 @@
# have a sensible pin default, the upstream one 'BlueZ'
# cannot be typed on a phone keypad!
echo 1234  $(DEB_DESTDIR)/etc/bluetooth/pin
+   chmod u=rw,go= $(DEB_DESTDIR)/etc/bluetooth/pin
 
 install/bluez-pcmcia-support::
chmod a+x $(DEB_DESTDIR)/etc/pcmcia/bluetooth
diff -u bluez-utils-3.5/debian/bluez-utils.postinst 
bluez-utils-3.5/debian/bluez-utils.postinst
--- bluez-utils-3.5/debian/bluez-utils.postinst
+++ bluez-utils-3.5/debian/bluez-utils.postinst
@@ -15,6 +15,19 @@
 set -e
 case $1 in
 configure)
+   # bluez-utils shipped with /etc/bluetooth/hcid.conf and 
+   # /etc/bluetooth/passkey readable by others so resetting 
+   # its permissions
+if [ -e /etc/bluetooth/hcid.conf ]  [ 'foo'$( find 
/etc/bluetooth/hcid.conf -perm +go=rwx ) != 'foo' ]; then
+   echo Security update: removing group and other permissions 
from file /etc/bluetooth/hcid.conf
+   chmod u=rw,go= /etc/bluetooth/hcid.conf
+   fi
+
+if [ -e /etc/bluetooth/passkeys ]  [ 'foo'$( find 
/etc/bluetooth/passkeys -maxdepth 0 -perm +go=rwx ) != 'foo' ]; then
+   echo Security update: removing group and other permissions 
from /etc/bluetooth/passkeys*
+   chmod -R u=rw,go= /etc/bluetooth/passkeys
+   fi
+
 # remove bluez-sdpd init, if present
if [ -f /etc/init.d/bluez-sdp ]; then
/usr/sbin/update-rc.d -f bluez-sdp remove
diff -u bluez-utils-3.5/debian/rules bluez-utils-3.5/debian/rules
--- bluez-utils-3.5/debian/rules
+++ bluez-utils-3.5/debian/rules
@@ -13,6 +13,7 @@
 # removed --enable-pcmcia --enable-dbus
 DEB_CONFIGURE_EXTRA_FLAGS := --disable-initscripts --enable-obex --enable-cups 
--enable-hid2hci 
 DEB_DESTDIR := $(CURDIR)/debian/tmp
+DEB_FIXPERMS_EXCLUDE := etc/bluetooth/*
 
 build/bluez-utils::
$(CC) `pkg-config --libs --cflags dbus-1` -DDBUS_API_SUBJECT_TO_CHANGE 
-o $(CURDIR)/debian/add-passkey $(CURDIR)/debian/add-passkey.c
@@ -43,6 +44,10 @@
# have a sensible pin default, the upstream one 'BlueZ'
# cannot be typed on a phone keypad!
echo 1234  
$(CURDIR)/debian/bluez-utils/etc/bluetooth/passkeys/default
+   chmod u=rw,go= 
$(CURDIR)/debian/bluez-utils/etc/bluetooth/passkeys/default
+   # tighten pin/passkey file and directory permissions
+   chmod