blueproximity can be bypassed to not force a lock

Bug #286820 reported by Michael Lustfield on 2008-10-21
Affects Status Importance Assigned to Milestone
blueproximity (Ubuntu)

Bug Description

I found a couple ways to bypass blueproximity.

First off, it's either this applet or another one that doesn't immediately detect the correct range. It can take a significant amount of time for the lock limit to be reached when the proximity isn't set very high.

This can give an attacker just enough time to get on the system and do a few malicious actions, or worse would be the following.

The second thing an attacker could do using either the gap of the maximum proximity or the afore mentioned is kill blueproximity. If an attacker just right clicks the applet and clicks quit or opens a terminal and uses kill (god forbid kill -9) they will not need to worry about what the maximum proximity is.

The best way I can think of to overcome this is have a blueproximity daemon. Once the daemon detects the blueproximity applet is killed, then the lock command is executed. Remembering that the daemon will run as root only and the user and blueproximity will not interact with this device other than when the daemon requests something.

This opens up another security concern. If this occurs then an attacker could quickly change the lock command. No only that, but they could change the proximity limit to the maximum. This will make the system stay unlocked until the device is completely out of range which takes a good distance to do. Yes - this can be done with changing MAC or

A simple resolve here would be to force any setting change to only become effective after a restart of the application. This could even be performed by a right click option. The point here being that it causes the application to detach and the system to lock. This will force the user to acknowledge any changes with minimal interruption.

1. Make the proximity detection more responsive
2. Force setting changes to only become effective after application restart
 - right click option for this
3. Run a daemon that detects detachment
4. Make all reboot signal a detach
5. Use last used setting for lock on detachment

Don't take any of this personally. I think this is an excellent application. I see that this could be extremely reliable at some point. Unfortunately, because of the items mentioned in this bug report, I don't see it as a secure setup.

Is nobody going to take consideration to these exploits? I've now used these exploits to bypass things exactly the way I described.

Changed in blueproximity:
status: New → Confirmed
Jamie Strandboge (jdstrand) wrote :

Thanks for filing a bug with Ubuntu. blueproximity is in universe and is community maintained. If you are able, I suggest posting a patch and/or contacting upstream so this issue can get resolved.

I will try to rewrite this application this summer. Perhaps some other developers will want to help me take on this task?

Chris Coulson (chrisccoulson) wrote :

Michael - woud you mind sending this upstream to blueproximity's bug tracker, which can be found here:


I'm not sure whether to link this to the SF bug tracker or not. I reported it there, but their LP page says that they use LP.

I can link it if somebody wants, otherwise I'll just leave the link.

Chris Coulson (chrisccoulson) wrote :

Thanks Michael. It seems that the Blueproximity project is set up to use Launchpad for bug tracking, so I'm not sure if you needed to submit it to the Sourceforge tracker (and we can't link to it and watch the bugs status anyway). Adding the Blueproximity task (which you've done now) is probably sufficient. Sorry about that!

Lars Friedrichs (l-friedrichs) wrote :

Hi Michael, Chris,

sorry to step into this conversation way too late. I changed my job last year's summer and bought a house too. So it's no wonder I had little time afterwards to move back to development on blueproximity.
It is true that I use LP now to track things like this.
I can confirm the bug you described above. Making it more responsive is not possible since bluetooth itself defines some parts here. Proximity checking intervals can be done only once per second and there is some algorithm behind the link quality detection inside the bluetooth stack which also gives slower reaction (normalization seems to take place there).
Possible ways to fix this: reduce the lock time and distance. If you leave your computer unlocked, move slower :-).

Generally it is no total security tool, it can be used in many creative ways. Locking is just the most obvious one. It is an extra security but you should not rely on it sorely. Please keep locking your computer manually too. Unlocking via blueproximity still works.

The other part is creating a daemon, I like the idea and it is on my list for blueproximity 2.0 (which itself is on the list for things to-do during the next 12 months but it has no priority at the moment)
Idea list includes:
- using a daemon for proximity checking
- using a user part for executing the commands (I cannot see a good (secure) way to have the commands be executed as the user other than this daemon)
- more devices to be scanned
- more events per device to be detected
- preset of commands (via plugin mechanism) to be executed
- setting up command chains via gui only
- keeping it simple enough to still work and look good and being usable by standard users

At the moment I am busy with work, family, house and in the sparetime I build a media pc for my mother, creating a nice complete remote control for an ipod touch for mythtv. I know there are some but none of them works as my mother would expect.

I think the reply suffices a fix.

Changed in blueproximity:
status: New → Invalid
Changed in blueproximity (Ubuntu):
status: Confirmed → Fix Released
Bruisah (apfbruce) wrote :

My tuppence on reading this (a bit late!). With respect to the dangers of an attacker meddling with the config of BP - simple fix would be to password protect the config...


To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.