The document discusses software security vulnerabilities, focusing on the importance of secure code in the context of consumer electronics, particularly smartphones and smart TVs. It outlines various threats, including malware and privacy invasions, while also providing examples of vulnerabilities in software and possible countermeasures such as secure coding practices, address space layout randomization, and using processor NX bits. The conclusion emphasizes that security is an ongoing process rather than a one-time solution.

1. Software security
Vulnerabilities, exploits and
November 14th,
possible countermeasures 2012
Roman Oliynykov
Associated Professor of Information Technologies Security
Department
Kharkov National University of Radioelectronics
Head of Scientific Research Department
JSC “Institute of Information Technologies”
Kharkov
Ukraine
ROliynykov@gmail.com

2. Lecture outline
 List of topics I suppose you already understand
 Importance of secure software for customers on the
modern highly competitive consumer electronics
market
 Example of vulnerable network daemon for Linux, and
exploit for it (buffer overflow demo)
 Possible countermeasures against software
vulnerabilities together with new hackers’ tricks against
them
 Need for permanent attention for software security

3. For this lecture
I suppose you understand
C programming language source code
 main terms of operation system architecture
(process, address space, stack, heap, etc.)
 x86 assembler language source code
(preferably AT&T notation)
 basics of Linux (command line)
 network utilities (ping, telnet)

4. Importance of secure software for
customers on the modern highly
competitive consumer electronics
market

5. Importance of secure software
 A smartphone is a mobile
phone built on a mobile
operating system, with more
advanced computing capability
and connectivity than a feature
phone [Wikipedia]
 Mobile operating system: Linux
(Android, Bada, etc.), potentially
vulnerable to malware (viruses,
worms, Trojan horses, etc.)

6. Financial threats to
smartphone users via malware
 Invisible to user automatic
premium number calls and SMS
 Mobile banking application
credentials theft via:
 mobile banking application attacks
(Zeus malware for mobiles, etc.)
 access to bank card readers
connected to the smartphone via
microphone port, NFC chip, etc.

7. Other threats to smartphone
users via malware
 Privacy threats (spying) for
remote transmission to the
hacker group:
 voice recording
 video and photo
 contact list, sms, etc.
 customer location via
GPS data, etc.
 Customer incrimination to
be a source of the
cybercrime attack when
his/her smartphone is a part
of the botnet

8. New attacks on smartphones:
‘visual malware’
Automated malicious software
based on camera photos for
3D model creation of indoor
environment and stealing data
of financial documents,
information on monitors, etc.

9. Importance of secure software
 A Smart TV is the phrase used to
describe the current trend of
integration of the Internet and Web
2.0 features into modern television
sets and set-top boxes, as well as the
technological convergence between
computers and these television sets
[Wikipedia]
 Mobile operating system: Linux
(Android, Bada, etc.), potentially
vulnerable to malware (viruses,
worms, Trojan horses, etc.)

10. Threats to Smart TV users:
almost the same
 Financial:
 banking application credentials theft
 Privacy threats (spying) for remote transmission to
the hacker group from customer’s house:
 voice recording
 video and photo
 blackmails for confidential recording at user’s home
 Family digital data lost (photos, videos, contacts,
etc. - example)
 Customer incrimination to be a source of the
cybercrime attack when his/her Smart TV is a part of
the botnet or hacker’s proxy node

11. Example of vulnerable network
daemon (service) for Linux,
and exploit for it

12. netcalcd – vulnerable daemon
(service) for Linux (x86)
 intentionally written for this lecture and
contains intentionally man-made
vulnerabilities
 processes simple network text requests for
basic calculations
 prints debug information about its stack on
the server console

13. netcalcd normal operation

14. netcalcd normal operation

15. netcacld source code:
part of the main() function

16. netcacld source code:
process_request() function

17. netcacld source code:
get_result() function

18. netcacld source code in asm:
get_result() function

19. Vulnerability in
get_result() function
strcpy( &dst, &src ) in contrast to
strncpy( &dst, &src, sizeof (dst) )
takes into account only
destination string length (buffer
size) and copies data until finds
termination zero in src

20. netcalcd stack after strcpy() call with
malicious data (hacker’s code) from the
network

21. netcalcd normal operation

22. Running exploit against
netcalcd

23. netcalcd buffer overflow in
get_result()

24. Open ports on the victim
computer: before and after

25. Victim computer successfully
cracked

26. What’s inside exploit and how
it works?

27. Exploit: usual C program for Windows
sending block of data (shellcode):

28. Shellcode in the example: relocatable
binary code can be run at any user address
Protect the running code in the stack, find absolute address it is
run at and decode the rest part of the shellcode

29. Why encode the main part of
the shellcode?

30. After encoding the rest part of the
shellcode runs web server at port 8801
or does everything
intruder wants to do with
the vulnerable process
privileges

31. How to protect our software
against such an attack?

32. Possible countermeasures
against buffer overflow
 write secure code based on secure functions calls
and all necessary user input verification (the most
important recommendation)
 make your operation system to use Address Space
Layout Randomization (ASLR)
 make your operation system use processor NX bit
(on x86 platform)
 keep on canary words in your compiler
 run the code with the least necessary privileges

33. Write secure code based on
secure functions calls
strcpy( &dst, &src ) fills destination buffer without taking into account its size;
strncpy( &dst, &src, sizeof( dst ) ) won’t write outside the destination buffer (but
it’s possible the lost of terminating zero)

34. Write secure code based on
secure functions calls
And many other recommendations for writing secure code…

35. Security check of existing
projects: automated tools
But no guarantee that all vulnerabilities are discovered

36. Address Space Layout
Randomization
computer security method which involves
randomly arranging the positions of key data
areas, usually including the base of the
executable and position of libraries, heap,
and stack, in a process's address space
[wikipedia]
Each running time stack, heap, etc. are put at
random addresses in the process address space

37. Address Space Layout
Randomization (example)
It’s difficult to guess correct return address to be written on the stack
smashing. But it is possible: only16 less bits of address are changed
Running code addresses are NOT changed

38. ASLR appeared:
 Linux kernel support: 2.6.12 (released June
2005)
 Microsoft's Windows Vista (released January
2007), Windows Server 2008, Windows 7,
and later have ASLR enabled by default
 Android 4.0 Ice Cream Sandwich provides
ASLR
…

39. ASLR evasion techniques
 brute force address search attempt
 return into code on non-randomized memory
 jmp *esp (ret address points to such bytes in code)
 etc.

40. Make your operation system use
processor NX bit (on x86 platform)
NX bit, which stands for Never eXecute, is a technology used in
CPUs to segregate areas of memory for use by either storage
of processor instructions (or code) or for storage of data

41. NX bit protection evasion:
return-to-libc attack
 no code in the stack (no
processor exception)
 return address is
overwritten and points to
the existing code
 intruder calls standard
function and passes
arbitrary arguments to it
 in Windows it is possible
to call a sequence of
functions due to _stdcall_
convention

42. Never switch off canary words
in your compiler
Canary words are known values that are placed between a buffer and
control data on the stack to monitor buffer overflows

43. Canary words
 Implementation:
 GCC Stack-Smashing Protector (ProPolice)
 Microsoft Visual Studio 2003 and higher ( /GS )
 etc.
 What cannot be handled:
 buffer overflows in the heap
(intruder uses pointers to functions in virtual
method tables of dynamic objects)

44. There is no universal silver
bullet for security
If a system switched on and running
we may have
up-do-date security solutions only
Security is a process, not a state

45. Conclusions (I)
 Security is important (and sometimes is a
crucial factor) for consumer acceptance
 Secure code is a major element of the secure
system
 Writing secure code is much more effective
than later security improvement

46. Conclusions (II)
 Effective
methods for security level
improvement for existing applications:
 Address Space Layout Randomization (ASLR)
 NX bit on x86 processors
 canary words in your compiler
 code running with the least necessary privileges

47. Conclusions (III)
 All acceptable security features of the
operation system should be used
 There is no universal “silver bullet” for
security
 Security is a process, not a state

48. Questions?