A survey of buffer overflow exploitation on htc touch mobile phone
Download
1 / 23

A survey of Buffer overflow exploitation on HTC touch mobile phone - PowerPoint PPT Presentation


  • 136 Views
  • Uploaded on

A survey of Buffer overflow exploitation on HTC touch mobile phone. Advanced Defense Lab CSIE NCU Chih-Wen Ou. Abstract. Buffer overflow issues on ARM based handheld devices (HTC touch mobile phone) Theoretical analysis and practical testing programming. Acknowledgement. 怡群

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'A survey of Buffer overflow exploitation on HTC touch mobile phone' - aileen


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
A survey of buffer overflow exploitation on htc touch mobile phone

A survey of Buffer overflow exploitation on HTC touch mobile phone

Advanced Defense Lab

CSIE NCU

Chih-Wen Ou


Abstract
Abstract

  • Buffer overflow issues on ARM based handheld devices (HTC touch mobile phone)

  • Theoretical analysis and practical testing programming


Acknowledgement
Acknowledgement

  • 怡群

  • Collin Mulliner

    • Exploiting PocketPC, What the Hack! July 2005.

  • Collin Mulliner

    • BlackHat Japen, October 2008

  • Everybody and 老師


Outline
Outline

  • Introduction

  • Background

  • Programming

  • Evaluation and Discussion

  • Future work

  • Conclusion


Introduction
Introduction

  • ARM based handheld devices

    • Most widely used processor

      • PDAs

      • GPS devices

    • Mobile phone devices

      • Symbian

      • WinCE

      • iPhone

  • Our test platform: HTC touch

    • ARM processor

    • Windows mobile 6.0 (WinCE 5)


Introduction1
Introduction

  • Buffer overflow issues

    • Without social engineering

    • Computer compromised

    • String data manipulation without proper bound check

    • Memory corruption and possible malicious execution flow redirection

  • shellcode programming on ARM based WinCE

    • ARM assembler and disassembler

      • Visual studio with windows mobile 6.0 sdk

    • ARM instruction set reference

    • C. Mulliner’s work since 2003


Background
Background

  • ARM

    • RISC Instruction set architecture

      • 32 bit word (4 bytes long)

      • Separated Instruction and data cache

    • Register organization (user32/system mode)

      • r0-r12 are general purpose register

      • r13 is stack pointer SP

      • r14 is subroutine link register LR

      • r15 is program counter PC


Background1
Background

  • WinCE

    • Slot virtual memory designed

      • 32-bit addressing, 4G address space

      • Divided into 32 MB sized slots

      • Slot 0 mapped for the “current execution” process

      • 33 slots used for user processes (including slot 0)

      • 1 slot for DLLs

      • Others slots used for kernel

      • Memory protection exists ( claimed by C. Mulliner)


Background2
Background

  • WinCE

    • Processes

      • Basically no thread limit (by C. Mulliner)

      • All processes share the same 4G virtual address space

      • Only few slots can be accessed by a certain process

    • XIP DLLs

      • eXecutin In Place DLLs

      • ROM

      • Function addresses are always the same (By C. Mulliner)


Background3
Background

  • C programming on WinCE

    • Dangerous string manipulation functions

      • Strcpy, strcat, sscanf…etc

    • Excution flow control variable in stack

      • LR is designed for resuming the execution address when subroutine call is finished

        • (mov pc,lr)

        • Hard to change the execution flow

      • Actually in our test program, saving return address in stack is still used on WinCE, when issuing a further subroutine call and current LR needs to be save in stack

      • The saved return address is always directly loaded to PC

        • (ldr pc, [sp],#4)

    • Buffer overflow vulnerabilities may exist!


Programming
Programming

  • Memory analysis program

    • Show the address of global variables

      • 0x000140dc (slot 0)

    • Show the address of local variables in stack

      • 0x??07fe7c (device)

      • 0x1807fe7c (emulator)

      • Different slot

    • Show the start address of function exectest()

      • 0x00011050 (slot 0)

    • Show the address of function MessageBoxW

      • 0x03f7f720 (fixed in slot 1)


Programming1
Programming

  • Execution flow redirection testing

    • By directly rewriting the guessed memory address of first local variable plus offsets

    • The new redirected address point to a static link compiled target procedure in code segment because of leak information of :

      • Execution in stack

      • Execution in global data

      • Execution among unknown memory layout


Programming2
Programming

  • Code and result


Programming3
Programming

  • Simple MessageBox pop up Shellcode

    • Call MessageBoxW(0,0,0,0) by directly issuing a function pointer call from 0x03f7f720

      • ((int(*)(DOWRD, DOWRD, DOWRD, DOWRD))(0x3f7f720))(0,0,0,0);

      • 感謝怡群

    • 32 bytes of 8 instructions

      • “\x00\x30\xa0\xe3” mov r3, #0

      • “\x00\x20\xa0\xe3” mov r2, #0

      • “\x00\x10\xa0\xe3” mov r1, #0

      • “\x00\x00\xa0\xe3” mov r0, #0

      • “\xfe\x47\xa0\xe3” mov r4, #0xEF, 14

      • “\x8e\x4e\x44\xe2” sub r4, r4, #0x8E, 28

      • “\x0f\xe0\xa0\xe1” mov lr, pc

      • “\x04\xf0\xa0\xe1” mov pc, r4


Programming4
Programming

  • According to result of analysis so far and the finished shellcode, we can write a test program on our HTC touch phone.

  • To test executing shellcode in global data area

  • To test executing shellcode in stack

  • Both above execution are launched by rewriting the return address in stack


Programming5
Programming

  • Code: execution in global data area


Programming6
Programming

  • Code: execution in stack


Evaluation and discussion
Evaluation and Discussion

  • Injected instruction in Stack

    • Success(emulator)

    • Failed (device)

  • Injected instruction in global data

    • success


Evaluation and discussion1
Evaluation and Discussion

  • Executing in stack failed

    • Instruction cache?

      • Global data is much closer to code segment composed of instructions compared to local variable, which is in stack

      • Therefore, global data may be cached into instruction cache with other instructions (just guessing…)

    • Address range?

      • Any execution limitation of program counter?

      • Other possible execution limitations cause such failure

  • Found GS function on WinCE

    • __security_check_cookie

    • I will test it in the future


Evaluation and discussion2
Evaluation and Discussion

  • Programs on ARM based WinCE platform

    • Extremely similar layout between emulator and HTC device.

    • No variation of layout when re-executing the program

    • Easy to decide addresses of functions within XIP DLLs without changed (ROM)

    • By default, GS function always protects our execution flow from control variable in stack being changed by malicious craft attacking string

Good for security


Evaluation and discussion3
Evaluation and Discussion

  • Programming on ARM based WinCE platform

    • Once program are compiled without GS on.

    • Once execution control variables can be changed through buffer overflow vulnerabilities

    • Once there is at least one enough writable global data space, especially string( because of XIP DLLs, may not be necessary)

    • We induce that such kind of program on a device is dangerous for compromising


Future work
Future work

  • Vulnerable program threat analysis

    • How much possibility for attacker changing the value of control variable in stack

    • GS function

  • Well attacking execution

    • Execution in global data

    • Execution by repeated calls within XIP DLLs

  • Completely proof of concept

    • A vulnerable program

      • buffer overflow vulnerable program on HTC touch phone

    • A classic attacking string

      • Malicious craft attacking string

    • A practical compromising

      • Download and execution … etc


Conclusion
Conclusion

  • Introduction of ARM register usage and its operation during subroutine call

  • WinCE memory layout analysis on emulator and HTC touch

  • Practical shellcode programming on ARM

  • Practical shellcode execution on HTC touch

  • GS function found


ad