Project

General

Profile

SamsungGalaxyBackdoor » History » Revision 11

Revision 10 (Paul Kocialkowski, 02/04/2014 06:43 PM) → Revision 11/25 (Paul Kocialkowski, 02/04/2014 06:55 PM)

h1. Samsung Galaxy Back-door 

 This page contains a technical description of the back-door found in Samsung Galaxy devices. 
 For a general description of the issue, please refer to the following statement:  

 *This back-door is present in most proprietary Android systems running on the affected Samsung Galaxy devices, including the ones that are shipped with the devices. However, when Replicant is installed on the device, this back-door is not effective: Replicant does not cooperate with back-doors.* 

 h2. Abstract 

 Samsung Galaxy devices running proprietary Android versions come with a back-door that provides remote access to the data stored on the device. 
 In particular, the proprietary software that is in charge of handling the communications with the modem, using the Samsung IPC protocol, implements a class of requests known as RFS commands, that allows the modem to perform remote I/O operations on the phone's storage. As the modem is running proprietary software, it is likely that it offers over-the-air remote control, that could then be used to issue the incriminated RFS messages and access the phone's file system. 

 h2. Known affected devices 

 The following table shows which devices are known to contain this back-door as part of the software they ship with. 
 Please contact us if you know about some other device that could be concerned by this back-door or have more information on one of the listed devices! 

 |_. Device |_. Incriminated program running as root |_. SELinux enabled |_. libsamsung-ipc support |_. Replicant support | 
 | Nexus S (I902x) | No | Possible with Android 4.2 and later | Yes | Yes | 
 | Galaxy S (I9000) | Yes | ? | Yes | Yes | 
 | Galaxy S 2 (I9100) | No | ? | Yes | Yes | 
 | Galaxy Note (N7000) | No | ? | Yes | Yes | 
 | Galaxy Tab 2 7.0 (P31xx) | No | ? | Yes | Yes | 
 | Galaxy Tab 2 10.1 (P51xx) | No | ? | Yes | Yes | 
 | Galaxy S 3 (I9300) | No | ? | Yes | Yes | 
 | Galaxy Note 2 (N7100) | No | ? | Yes | Yes | 

 h2. Back-door  

 In order to investigate the back-door and check what it actually lets the modem do, some code was added to the modem kernel driver to make it craft and inject requests using the incriminated messages and check its results. 

 h2. Analysis 

 The following analysis was conducted using the @libsec-ril.so@ binary file (the incriminated proprietary software) as extracted from the CyanogenMod 10.1.3 system zip for the Galaxy S 3 (I9300), from location @system/lib/libsec-ril.so@. 

 *The developers involved in the present analysis did not ever agree to any sort of End User License Agreement that explicitly prohibited the reverse engineering and decompiling operations of the incriminated binary. The reverse engineering operations that led to these findings originally took place during the development of [[Samsung-RIL]], the free software replacement for the incriminated program. Hence, we believe these operations were conducted for the sole purpose of interoperability and not with the intent of creating a competing product. As the involved developers were based in Europe, we believe the legality of these operations is granted by article 6 of the 1991 EU Computer Programs Directive.* 

 As a first approach, using the @strings@ tool against the incriminated program reveals numerous suspicious command names that appear to be Samsung IPC protocol definitions: 
 <pre> 
 IPC_RFS_READ_FILE 
 IPC_RFS_WRITE_FILE 
 IPC_RFS_LSEEK_FILE 
 IPC_RFS_CLOSE_FILE 
 IPC_RFS_PUT_FILE 
 IPC_RFS_GET_FILE 
 IPC_RFS_RENAME_FILE 
 IPC_RFS_GET_FILE_INFO 
 IPC_RFS_UNLINK_FILE 
 IPC_RFS_MAKE_DIR 
 IPC_RFS_REMOVE_DIR 
 IPC_RFS_OPEN_DIR 
 IPC_RFS_READ_DIR 
 IPC_RFS_CLOSE_DIR 
 IPC_RFS_OPEN_FILE 
 IPC_RFS_FTRUNCATE_FILE 
 IPC_RFS_GET_HANDLE_INFO 
 IPC_RFS_CREATE_FILE 
 </pre> 

 The names of these commands make it obvious that they let the modem perform I/O operations. 

 The @strings@ utility also reveals matching function names that seem to implement the handling of these commands: 
 <pre> 
 RxRFS_GetFile 
 RxRFS_CreateFile 
 RxRFS_ReadDirectory 
 RxRFS_OpenDirectory 
 RxRFS_RenameFile 
 RxRFS_Default 
 RxRFS_OpenFile 
 RxRFS_ReadFile 
 RxRFS_FtruncateFile 
 RxRFS_WriteFile 
 RxRFS_GetFileInfoByHandle 
 RxRFS_GetFileInfo 
 RxRFS_PutFile 
 RxRFS_LseekFile 
 RxRFS_CloseFile 
 RxRFS_DeleteFile 
 RxRFS_MakeDirectory 
 RxRFS_CloseDirectory 
 RxRFS_RemoveDirectory 
 TxRFS_CfrmCreateFile 
 TxRFS_CfrmPutFile 
 TxRFS_CfrmOpenDirectory 
 TxRFS_CfrmGetFileInfo 
 TxRFS_CfrmReadDirectory 
 TxRFS_CfrmRenameFile 
 TxRFS_CfrmCloseFile 
 TxRFS_CfrmFtruncateFile 
 TxRFS_CfrmGetFileInfoByHandle 
 TxRFS_CfrmDeleteFile 
 TxRFS_CfrmCloseDirectory 
 TxRFS_CfrmRemoveDirectory 
 TxRFS_CfrmMakeDirectory 
 TxRFS_CfrmGetFile 
 TxRFS_CfrmReadFile 
 TxRFS_CfrmWriteFile 
 TxRFS_CfrmLseekFile 
 TxRFS_CfrmOpenFile 
 </pre> 

 Taking a closer look at these functions, using the @objdump@ decompiler, reveals that they are actually called from the @ipc_recv_rfs@ function, itself called from @process_ipc_notify_message@, which appears to handle the received messages from the modem. Hence we can deduct that the incriminated functions are actually called upon modem request. 

 Taking a closer look at one of these functions, e.g. RxRFS_ReadFile reveals multiple calls to the Procedure Linkage Table (PLT). Hence we believe these calls are linked functions from the libc library, especially I/O-related functions such as (in a general manner) @open@, @close@, @read@, @write@, etc. 

 h2. Samsung IPC RFS messages 

 The following table associates each Samsung IPC RFS message with its hexadecimal command value: 

 |_. Message |_. Hexadecimal command value | 
 | IPC_RFS_NV_READ_ITEM | 0x01 | 
 | IPC_RFS_NV_WRITE_ITEM | 0x02 | 
 | IPC_RFS_READ_FILE | 0x03 | 
 | IPC_RFS_WRITE_FILE | 0x04 | 
 | IPC_RFS_LSEEK_FILE | 0x05 | 
 | IPC_RFS_CLOSE_FILE | 0x06 | 
 | IPC_RFS_PUT_FILE | 0x07 | 
 | IPC_RFS_GET_FILE | 0x08 | 
 | IPC_RFS_RENAME_FILE | 0x09 | 
 | IPC_RFS_GET_FILE_INFO | 0x0a | 
 | IPC_RFS_UNLINK_FILE | 0x0b | 
 | IPC_RFS_MAKE_DIR | 0x0c | 
 | IPC_RFS_REMOVE_DIR | 0x0d | 
 | IPC_RFS_OPEN_DIR | 0x0e | 
 | IPC_RFS_READ_DIR | 0x0f | 
 | IPC_RFS_CLOSE_DIR | 0x10 | 
 | IPC_RFS_OPEN_FILE | 0x11 | 
 | IPC_RFS_FTRUNCATE_FILE | 0x12 | 
 | IPC_RFS_GET_HANDLE_INFO | 0x13 | 
 | IPC_RFS_CREATE_FILE | 0x14 | 
 | IPC_RFS_NV_WRITE_ALL_ITEM | 0x15 | 

 h2. Legitimacy 

 The incriminated RFS messages of the Samsung IPC protocol were not found to have any particular legitimacy nor relevant use-case. However, it is possible that these were added for legitimate purposes, without the intent of doing harm by providing a back-door. Nevertheless, the result is the same and it allows the modem to access the phone's storage. 

 However, some RFS messages of the Samsung IPC protocol are legitimate (IPC_RFS_NV_READ_ITEM and IPC_RFS_NV_WRITE_ITEM) as they target a very precise file, known as the modem's NV data. There should be no particular security concern about these as both the proprietary implementation and its free software replacement strictly limit actions to that particular file. 

 h2. Notes 

 Our free software replacement for the incriminated binary is [[Samsung-RIL]] which relies on [[Libsamsung-ipc|libsamsung-ipc]] and is used in Replicant. 

 The affected devices have modems that use the Samsung IPC protocol, mostly Intel XMM6160 and Intel XMM6260 modems. Note that despite this back-door, the devices using these modems are most likely to have good modem isolation, compared to other devices using Qualcomm platforms. Bear in mind that this back-door is implemented in software and can easily be removed by installing a free replacement for the incriminated software, for instance by installing Replicant. Hence, we don't consider the incriminated devices to be inherently bad targets because of this back-door.