vuln.sg  

vuln.sg Vulnerability Research Advisory

ALPass Password File Import Buffer Overflow Vulnerability

by Tan Chew Keong
Release Date: 2007-08-24

   [en] [jp]

Summary

A vulnerability has been found in ALPass. When exploited, the vulnerability allows execution of arbitrary code when the user imports Site Information from a specially-crafted ALPass DB File (APW).


Tested Versions

  • ESTsoft ALPass version 2.7 (English) (ALPass.exe file version 2.70.24.6112)

NOTE: ALPass version 3.02, which is available in Korean language, is also affected. However, the stack-based buffer overflow vulnerability is not easily exploitable in version 3.02 (Korean) as the binary is compiled with stack-based buffer overflow protection.


Details

ALPass has a "Import Site Information" feature that allows the user to import site information from a ALPass DB File (APW). This site information, which includes site URL, usernames, passwords, etc, is stored AES-encrypted within the APW file. This information can be decrypted using an APW file-key that is stored encrypted within the same APW file. The APW file-key is AES-encrypted using a password that is provided by the user.

The following sample APW file illustrates this. The string of characters after "ck:" is the hex-encoded APW file-key which is encrypted with the user supplied password.

1) Exploitable Stack-based Buffer Overflow

When importing a APW file, ALPass requires the user to input a password to decrypt the content of the import file. ALPass reads the hex-encoded APW file-key from the APW import file, decodes it into binary, and stores it into a heap-buffer. Subsequently, ALPass uses the user supplied password to AES-decrypt the APW file-key into a 4096-bytes stack buffer.

It is possible to create a specially-crafted APW file that contains an overly long file-key, as illustrated below.

A stack-based buffer overflow occurs in ALPass when it decrypts the overly long file-key into the 4096-bytes stack buffer. In order to exploit this vulnerability successfully, the user must be convinced to import site information from a malicious ALPass DB file (APW). Execution of arbitrary code using this vulnerability has been confirmed on English WinXP SP2 with ALPass version 2.7 (English).

The following screen capture shows that it is possible to overwrite the saved EIP using this vulnerability.


2) Other Insecure Coding Issues

Two instances of insecure coding issues were also found within ALPass.exe. Both ALPass version 2.7 (English) and ALPass version 3.02 (Korean) are affected. These two issues are not as easily exploitable as compared to the stack-based buffer overflow vulnerability and are not necessarily exploitable for code execution. But nonetheless, they should be fixed to avoid possible problems.

Issue 1: Incorrect use of sprintf() when handling folder names (format-string issue)

ALPass allows the creation of folders in the password file to facilitate the organisation of Site Information. When importing a ALPass DB file (APW) from an external source, the folder-name record is read from the APW file and decrypted. The following shows the content of the decrypted folder-name record.


fnm:TESTFOLDER
sp:y
fid:1
pid:0


The folder-name, which is prefixed by "fnm:", is then passed to the sprintf() function without any sanitisation. This causes a format-string issue, which can cause the application to crash either by writing to memory locations (using %n), or by overflowing the output buffer (using %.10000X). For example, by asking the user to import a specially-crafted APW file that contains "fnm:%n%n%n%n%n%n%n%n" as the folder-name, the following call to sprintf() will result: sprintf(buffer, "fnm:%n%n%n%n%n%n%n%n").

In this particular code path, the format string does not exist on the stack-buffer. This makes it difficult for the attacker to overwrite controllable memory locations using this issue. Nonetheless, input from non-trusted sources should not be used directly as sprintf()'s format string without proper sanitisation. The unsafe sprintf() call is illustrated below.

Issue 2: Overflow of malloc'ed heap buffer

Each Site Information and Folder entry in a ALPass DB file (APW) is stored as an AES-encrypted record. Each encrypted record is preceded by two DWORD length values, the ciphertext_length and the plaintext_length values. To be exact, the value of ciphertext_length is actually the "length of the ciphertext" + sizeof(DWORD). i.e. "length of the ciphertext" + 4

This is illustrated below. The ciphertext_length value is underlined in red, the plaintext_length value is underlined in yellow.

In the example above, the actual length of the ciphertext is 0x34 - 4 = 0x30, whereas the length of the plaintext is 0x21 (when the ciphertext is decrypted). When ALPass is parsing the record, it will allocate ciphertext_length (e.g. 0x34) bytes of memory using malloc(), and then read both the plaintext_length DWORD-value and the ciphertext from the APW file into the allocated buffer.

Next, ALPass will attempt to decrypt the ciphertext. In order to do that, ALPass first allocates (using malloc()) a decryption heap buffer of "plaintext_length + 0x10C" bytes to store the decrypted record. Subsequently, the encrypted record (ciphertext) will be decrypted into this buffer. Allocation of the decryption buffer is done without checking whether the actual value of ciphertext_length (i.e. the length of the ciphertext) is much larger than "plaintext_length + 0x10C" bytes.

This makes it possible to create a specially-crafted APW file such that the ciphertext_length value (i.e. the length of the ciphertext) is much larger than the value of "plaintext_length + 0x10C". This will cause ALPass to read a large amount of ciphertext from the APW file and decrypts it into a small decryption buffer, thus overflowing the buffer.

An encrypted record with specially-crafted ciphertext_length value is shown below. When parsing this record, ALPass will cause 0x1030 bytes of ciphertext to be decrypted into a 0x10C + 0x21 = 0x12D byte malloc'ed buffer. This overflows the malloc'ed heap buffer.


POC / Test Code

The following POC APW files will exploit the vulnerability to run calc.exe or crash ALPass 2.7. The code execution POC has been successfully tested on English WinXP SP2 with English ALPass version 2.7.


Instructions to reproduce the vulnerability:

  1. Download the POC files and save them to the hard-disk.
  2. Run ALPass.
  3. Create a new user in ALPass.
  4. Logon to ALPass using the new user.
  5. Select "Import/Export Site Info..." from main menu. The "Import/Export Site Information" dialog box will appear
  6. Select "Import File" and click the "Next" button.
  7. Choose one of the POC files for import.
  8. Type in password as the password of the APW import file.
  9. Click on the "Next" button to begin import.
  10. Successful exploit will run calc.exe or crash ALPass.
 


Patch / Workaround

Update to version 2.74 (English). The Korean version will be fixed soon. Vendor's ALPass version history.


Disclosure Timeline

2007-08-08 - Vulnerability discovered.
2007-08-08 - Initial vendor notification.
2007-08-09 - Initial vendor reply.
2007-08-09 - Vulnerability description and POC files sent to vendor.
2007-08-12 - Addition issues sent to vendor.
2007-08-23 - Vendor released English fixed version.
2007-08-24 - Public disclosure.


Contact
For further enquries, comments, suggestions or bug reports, simply email them to