Repost: Stack-based Buffer Overflow Vulnerabilities in Embedded Systems

The buffer overflow attack vector is well documented in desktop and server class machines using the von Neumann memory model, but little has been published on buffer overflow vulnerabilities in Harvard architectures.

I have not written or contributed to the enclosed research paper. I’m simply reposting it here because it’s interesting and for some reason, appears available only via Google cache. So before it disappear from results, I’m reposting it here.

This paper discusses a technique to conduct buffer overflows on processors using the Harvard architecture. In this architecture, the stack starts at the beginning of the memory and grows up, versus Von Neumann architectures in which it grows down.


Most small embedded devices are built on Harvard class microprocessor architectures
that are tasked with controlling physical events and, subsequently, critical infrastructures. The Harvard architecture separates data and program memory into independent address spaces, as opposed to the von Neumann architecture that uses a unified memory system with a single address space for both data and program code. The buffer overflow attack vector is well documented in desktop and server class machines using the von Neumann memory model, but little has been published on buffer overflow vulnerabilities in Harvard architectures. In this paper we show that stack-based buffer overflow vulnerabilities exist in embedded control devices based on the Harvard class architecture. We demonstrate how a reversal of stack growth direction can greatly simplify the attack and allow for easier access to critical execution controls. We also examine popular defense techniques employed in server and desktop environments and the applicability of those defenses toward Harvard class machines.
Link: Kristopher Watts & Paul Oman, University of Idaho, Stack-based Buffer Overflow Vulnerabilities in Embedded Systems

Starting in Exploit Development – Day 04

Today, instead of following the FuzzySecurity tutorial, I’ve decided to solidify what I have learned so far by exploiting another FTP Server, this way we won’t yet stray far from the tutorial. We’ll exploit the PCMAN FTP 2.07 server.

The exploit is a buffer overflow in about any command send to the FTP server. We’ll attempt to exploit the STOR command. To do so, we basically reconstruct the Python script we’ve used in day 1:

Note that we are using a buffer of 3000 bytes. I’ve first attempted a payload size of 2000, but it failed to crash the server. At 3000, it was successful as you can see below:

Buffer Overflow in PCMAN FTP 2.07
We successfully smashed EIP with a payload of 3000 bytes in the STOR command.

Let’s replace our payload by a Metasploit pattern to find the offsets using !mona findmsp:

Mona showing at which offset EIP is overwritten
Mona found that EIP is being overwritten at offset 2006

Also interesting, is that SEH is not being overwritten here, so we cannot use the technique learned yesterday. The offset found, we can now start shaping our payload:

And we’ll test it to confirm everything is going smoothly:

EIP overwritten with "B"s
Our payload works, now we simply have to put the addresses and shell code needed

Ah ! Perfecto ! Now let’s figure out an address we can use to jump at [ESP]. We’ll do this using !mona jmp -r esp:

Search results for "jmp esp" in PCMAN 2.07
Search results for “jmp esp” instructions in memory for PCMAN FTP Server 2.07

Ideally, I would have like to find a “jmp esp” within the application itself, but all of them contained invalid bytes, so I’ll just use one from the Windows DLLs:

We’ll use the same payload as before, i.e. the windows\shell_bind_tcp as we are only interested in training purposes, so our final code will look like this:

And voila! I sometimes runs into issue when running the shell code on the target machine and it seems due to bad bytes in the shell, so this is something I’ll need to check out, i.e. how to determine which bytes should be avoided in the shell code. I usually fix it by regenerating a new payload in Metasploit. In any case, we have out shell:

Listening on port 4444
The exploit binded a shell on port 4444
Remote Shell from Exploiting PCMAN FTP 2.07
We successfully open a remote shell from the exploit in PCMAN FTP 2.07

All right, so now, we should be able to exploit basic buffer overflows from any simple program. Let’s move on…

Internet Explorer 7 Attack in the Wild

Bits of information about the new 0-day exploit are surfacing on the web. This exploit provokes a heap overflow in the XML parser of Internet Explorer 7. The exploit works with the fully patched version of Windows XP, Windows Server 2008 and Windows Vista SP1[1].

The Infection

The exploit is initiated by a JavaScript file stored on infected servers across the web. The example given by the SANS Internet Storm Center is located at http://17gamo [dot] com/1.js. F-Secure also reported the URL as being infected. The content of the JavaScript file is injected through sites by a SQL injection attack and it contains a link to a web page containing the exploit and the shellcode. A complete list of infected websites can be found at Shadowserver.

The contents of the 1.js file (be careful of what you do with this info!):

The SQL injection works by adding a link to every text field contained in an accessible database. Therefore, once text contained in the database is retrieved to be displayed on the webpage, the malicious link to the JavaScript is also included in it and executes the contents of the file, which contains two statements.  One is a counter to measure how many victimes it made, the other is an iFrame to the malicious webpage. The SQL injection usually takes this form, but it really depends on which software is attacked:

The Exploit

This is part of the JavaScript found in the while. It checks the version of the browser and OS and triggers the buffer overflow:

You can get a working example at

The script used in the wild waits for 6 seconds before starting, apparently to fool anti-viruses. It then verifies if the current browser is Internet Explorer and if it’s version 7. It also checks that the OS is Windows XP or 2003 (but the exploit does work in Vista also). If all conditions are met, the script will then write the malformed XML code to exploit to the parser. The loop at the end keeps the status bar from displaying any information to the user. The parsing of the XML code will trigger a heap overflow in the parser and arbitrary code can be executed.

The vulnerability is explained more in detailed by the Chinese researchers[2] that first discovered the exploit and that released the code by mistake. The original article is written in Mandarin, but a rough translation from Google leads to a mistake in the handling of pointers when “SDHTML objects” are created. A machine translated post on a forum gave that information[3]:

Recently caught using IE7 0day vulnerability code, as in dealing with the object SDHTML errors lead to memory disorders, through the structural conditions of a specific code lead to cross-border memory. 现已有人赶制出网马生成器相信会在短期内流行。 It was now working towards a network of horse generator, will be popular in the short term. 该漏洞存在于IE7XML可以导致内存越界的漏洞攻击者通过构造畸形XML代码并且使用JavaScript脚本操作ShellCode去执行任意代码。 The vulnerability exists in IE7’s XML, the memory can lead to cross-border loopholes, the attacker through the abnormal structure using JavaScript and XML code script ShellCode operation to execute arbitrary code.
漏洞描述 Description of the loopholes:
由于SDHTML里处理对象存在错误导致内存紊乱通过构造某种条件可以使得SDHTML检测到错误释放已被分配的对象但是在释放已被分配的对象后SDHTML并未返回而是继续使用被释放的对象的内存执行如果这些内存又被分配给其他用途将导致SDHTML把这些内存当作一个对象来操作。 SDHTML due to errors in handling the object lead to memory disorders, through some kind of structural conditions can make mistakes SDHTML detected the release of the allocation has been the target, but the release has been the target of the distribution did not return after SDHTML be released but continue to use the object The implementation of the memory, if memory has been allocated to other purposes, such SDHTML will lead to memory as an object to the operation. 攻击者使用了XMLSRC字符串对象占用了这些释放对象的空间而对象指针里包含函数例程指针最终导致代码执行。 An attacker using the XML string SRC release of these objects taking up space objects, and object pointer included in routine function pointer, leading to the implementation of the code.

This hole wasn’t patch with the latest update from Microsoft. No details are available on when a hotfix will be distributed. Disabling Active Scripting will prevent this exploit from downloading the Trojan. Doing so will also protect anyone from most of the online attacks (but it will also make some sites unusable). Other solution: use Firefox or Opera. And for the geekiest, you can always use the safest browser around by downloading it here.

Observed Payload

Right now, it seems these attacks using this exploit are limited to MMORPG password stealers. The shellcode included with the current exploit will download http://www [dot] steoo [dot] com/admin/win.exe[4]. F-secure detect the trojan contained in the file as Win32.Magania and as Infostealer.Gamania[5] by Symantec. This malware is a game password stealing Trojan for games created by the Taiwanese company Gamania, creator of Maple Story amongst others.

The trojan will create various files into the %SYSTEM% directory and add himself in the registry so that it boots every time the computer starts. Files created include[6]:

  • %System%\Kerne0223.exe
  • %System%\Kerne0223.dll
  • %Windir%\SVCH0ST.EXE
  • %System%\aer4532gxa.dll (detected as Infostealer.Lineage)
  • [PATH TO TROJAN]\gg.bat
  • %System%\drivers\etc\hosts
  • c:\log.txt

And will steal every credentials entered by the user on these sites:

  • [http://]
  • [http://]
  • [http://]
  • [http://]
  • [http://]
  • [http://]
  • [http://]
  • [http://]
  • [https://]
  • [https://]
  • [https://]
  • [https://]
  • [https://]
  • [https://]
  • [https://]
  • [https://]
  • [https://]
  • [https://]
  • [https://]
  • [https://]
  • [https://]
  • [https://]
  • [https://]
  • [https://]
  • [https://]

It is strongly believed that this Trojan origin is based in China. Various variants of this Trojan have been created. Variants may come with a keylogger and rootkits.

See also:

“Microsoft Security Advisory (961051)”, Microsoft, December 10, 2008, (accessed on December 11, 2008)

“Mass SQL Injection”, F-Secure, December 11, 2008, (accessed on December 11, 2008)

“Chinese researchers inadvertently release IE7 exploit code”, John Leyden, The Register, December 11, 2008, (accessed on December 11, 2008)

Add to FacebookAdd to NewsvineAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to Ma.gnoliaAdd to TechnoratiAdd to Furl

[1] “0-day exploit for Internet Explorer in the wild”, Bojan Zdrnja, SANS Internet Storm Center, December 10, 2008, (accessed on December 11, 2008)

[2] “Alert: IE70DAY attack code has been linked to the use of  Trojan Horse”, December 12, 2008, (accessed on December 11, 2008 – Eastern Time GMT-5)

[3] Translated by Google Translate from Chinese, (accessed on December 11, 2008)

[4] “0-day exploit for Internet Explorer in the wild”, Bojan Zdrnja, SANS Internet Storm Center, December 10, 2008, (accessed on December 11, 2008)

[5] “Infostealer.Gamania”, Hiroshi Shinotsuka, Symantec, February 13, 2007, (accessed on December 11, 2008)

[6] Ibid.

New Kid on the Block: Downadup

Many reports on the last few days mention a new worm growing on the back of the Windows’ MS08-067 vulnerability. The worm named Downadup, also being dubbed Conficker.A by Microsoft, as now spread to alarming levels: “We think 500,000 is a ball park figure” said Ivan Macalintal, a senior research engineer with Trend Micro Inc[1].

The Exploit

The vulnerability is located in the Windows Server service, which is used to share networks files and printers across computers on a Windows network. This service is used by all Windows versions, even the Windows 7 Pre-Beta version, therefore making every Windows user vulnerable unless patched[2]:

Microsoft Windows 2000 Service Pack 4 Windows Server 2003 with SP1 for Itanium-based Systems
Windows XP Service Pack 2 Windows Server 2003 with SP2 for Itanium-based Systems
Windows XP Service Pack 3 Windows Vista and Windows Vista Service Pack 1
Windows XP Professional x64 Edition Windows Vista x64 Edition and Windows Vista x64 Edition Service Pack 1
Windows XP Professional x64 Edition Service Pack 2 Windows Server 2008 for 32-bit Systems*
Windows Server 2003 Service Pack 1 Windows Server 2008 for x64-based Systems*
Windows Server 2003 Service Pack 2 Windows Server 2008 for Itanium-based Systems
Windows Server 2003 x64 Edition Windows Server 2003 x64 Edition Service Pack 2

Vulnerable Operating System by the MS08-67 Exploit

The exploit is executed by sending a specially crafted packet to the RPC (Remote Procedure Call) interface. The interface could be reach by an attacker if there are no firewalls activated or if the File/Printer sharing options is enabled and connected to the Internet. The packet will cause a buffer overflow which allows arbitrary code to be executed.

The core of the exploit comes from a buffer overflow created when parsing a specific path. The exploit occurs when specially crafted packet is sent to port 139 or 445 on a Windows file/printer sharing session. The reception of that package will trigger a call to the RPC API NetPathCompare() and NetPathCanonicalize() functions.

The exploit is triggered when giving a specific path to canonicalize, such as “\c\..\..\AAAAAAAAAAAAAAAAAAAAAAAAAAAAA”[3] to the NetPathCanonicalize function, which uses the _tcscpy_s macro, which in turns calls the wcscpy_s function[4]. This function is used to copy a wide-character string from a location in memory to another. The buffer overflow is provoked by a miscalculation in the parameters given to the _tcscpy_s macro by the NetPathCanonicalize() function.

The _tcspy_s function is called like this by the NetPathCanonicalize:

_tcscpy_s(previousLastSlash, pBufferEnd – previousLastSlash, ptr + 2);

NetPathCanonicalize contains a complex loop to check the path for dots, dot-dots, slashes while making a lot of pointer calculations. Once the loop is passed over a couple of time, the previousLastSlash parameter gets an illegal value.

The RPC call

To exploit this vulnerability, all one have to do is to bind with the SRVSVC pipe of the Windows Server Service, which is the RPC interface and bind with it. If this is successful, a call to the NetPathCanonicalize()function with a specially crafted path as shown above, is done, then it’s only a matter of providing the payload. Exploits are already public on sites such as milw0rm[5].

The New Worm: Downadup

Downadup is the new worm to use the exploit on a large scale and has proved to be widely successful even if it’s already been one month since the vulnerability was found and patched.

Once installed on a system, the worm will copy itself with a random name into the system directory %systemroot%\system32 and register itself as a service[6]. It will, of course, also add itself into the registry with the following key:

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<name>.dll
    ImagePath = %SystemRoot%\system32\svchost.exe -k netsvcs
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\netsvcs\Parameters\”ServiceDll” = “<name>.dll”

It will then use those sites to get the newly infected machine’s IP address:


With the IP address, Downadup can download a small HTTP server (““) and open a HTTP server on the current machine with the following address[7]:


Once the HTTP server is set up, it will scan for other vulnerable machines and when a target is found, the infected machine URL will be sent to the target as the payload. The remote computer will then download the worm from the URL given and then start to infect other machines as well. Therefore, there is no centralized point of download. Upon successful infection, it will also patch the hole to prevent other worms to infect the machine[8].

According to Symantec, it has a domain name generating algorithm based on dates just like the Srizbi has (see Srizbi is back for more details on the algorithm). It also deletes any prior Restore Points saved by the user or the system[9].

Add to FacebookAdd to NewsvineAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to Ma.gnoliaAdd to TechnoratiAdd to Furl

[1] “New Windows worm builds massive botnet”, Gregg Keizer, ComputerWorld, December 1, 2008, (accessed on December 1, 2008)

[2] “Microsoft Security Bulletin MS08-067 – Critical”, Microsoft, October 23, 2008, (accessed on December 2, 2008)

[3] “Gimmiv.A exploits critical vulnerability (MS08-067)”, Sergei Shevchenko, October 23, 2008, (accessed December 2, 2008)

[4] “MS08-067 and the SDL”, The Security Development Lifecycle, October 22, 2008, (accessed on December 2, 2008)

[5] See MS08-067 Exploit by Debasis Mohanty and MS08-067 Remote Stack Overflow Vulnerability Exploit for examples.

[6] “F-Secure Malware Information Pages: Worm:W32/Downadup.A”, F-Secure Corporation, November 26, 2008, (accessed on December 2, 2008)

[7] “W32.Downadup”, Symantec, Takayoshi Nakayama and Sean Kiernan, November 24, 2008, (accessed on December 2, 2008)

[8] “Microsoft warns of new Windows attacks”, Gregg Keizer, ComputerWorld, December 1, 2008, (accessed on December 2, 2008)

[9] “Worm:Win32/Conficker.A”, Joshua Phillips, Microsoft Malware Protection Center, 2008, (accessed on December 2, 2008)

Attacking the Vista Kernel

CNet reported not long ago about a new vulnerability found in the kernel of Vista[1]. The attack is a buffer overflow which corrupts the memory, and thus could be use for denial of service attacks. The report from Phion, the security company that reported the vulnerability, also states that the attack could be used to inject code[2].

There is a new vulnerability found in the kernel of Vista . The attack is a buffer overflow which corrupts the memory
There is a new vulnerability found in the kernel of Vista. The attack is a buffer overflow which corrupts the memory

The buffer overflow is caused by adding an IP address with an illegal subnet bits value to the IPv4 routing table: For example the following command will make Vista crash with a blue screen of death:

C:>route add

In the command above, we specified 254 as being the number of subnet bits, which is an illegal value. According to the vulnerability report by Thomas Unterleitner, the greater the value is, the quicker the crash is provoked[3].

The overflow is located into the CreateIpForwardEntry2 method which is part of the Iphlpapi library (Iphlpapi.dll). The problem arises because the method doesn’t verify the value of the PrefixLength property of DestinationPrefix specified in the MIB_IPFORWARD_ROW2 structure passed to the method. Therefore, the following code should crash the kernel[4]:

In order for this code to work you must be in the Administrators group or in the Network Operators Group…so it’s of limited use for most people, but you never know…

Microsoft said it had no intention of patching this buffer overflow before the next Vista service pack[5]. This exploit doesn’t apply to Windows XP.

[1] “Kernel vulnerability found in Vista”, David Meyer, CNet Security, November 22, 2008, (accessed on November 25, 2008)

[2] “Microsoft VISTA TCP/IP stack buffer overflow”, Thomas Unterleitner, November 19, 2008, (accessed on November 25, 2008)

[3] Ibid.

[4] Ibid. Code by Thomas Unterleitner

[5] “Vista kernel is vulnerable”, Egan Orion, The Inquirer, November 24, 2008, (accessed on November 25, 2008)