‘Multiple Security Vulnerabilities in Sharp Zaurus’


‘The Sharp Zaurus SL-5000D and SL-5500 have multiple security vulnerabilities in design and implementation that affect system security.

The first vulnerability gives a remote attacker full control of the Zaurus filesystem, including the ability to overwrite files and/or programs with Trojans.

The second vulnerability affects the Zaurus passcode function, which locks the Zaurus so that no data can be input via the keypad and touch screen.’


‘The information has been provided by Dr. Steve Chapin, Douglas F. Calvert, David Walter, K. Reid Wightman, Niranjan Sivakumar.’


Vulnerability 1: Remote filesystem access
The Sharp(R) Zaurus(tm) SL-5000D and SL-5500 handhelds use FTP for performing sync operations with a PC. The FTP daemon on both Zaurus models is built into QPE, the default windowing system for the units, on port 4242. The daemon binds to all network interfaces on the Zaurus, including any wireless network or PPP interfaces.

This FTP service gives any remote user access to the Zaurus filesystem as root, via any network interface. Setting the root password on the Zaurus has no effect, as the FTP daemon does not actually authenticate the user. By default, the Zaurus has no root password.

Vulnerability 2: Passcode
The Zaurus stores the screen-locking passcode in the file /home/root/Settings/Security.conf. The passcode program uses the same salt value every time the passcode is set: A0. Knowing this, a cracker can generate a passcode table approximately 4G in size, which can be used to look up the passcode given the file Security.conf.

Vulnerability 1: Remote filesystem access
Zaurus users who use Ethernet or PPP to attach to a network should either discontinue use of QPE or place themselves behind a firewall until a patch for QPE is released.

Vulnerability 2: Passcode
This issue is larger than it sounds. Changing the passcode utility so that it does a crypt() call on plaintext passcode, using a new salt value each time, is difficult because the Zaurus generates very little random number data.

Only interrupts from the keyboard and front buttons call add_interrupt_randomness() in the kernel. Screen taps do not, nor do CompactFlash events. Many users will only input via the screen, using handwriting recognition or the built-in software keyboard. Changing the interrupt handler for the screen to call add_interrupt_randomness() should add sufficient entropy to the random number pool to generate a sufficiently random salt on the fly.

Vendor status:
Sharp Support has been notified of both issues and responded 7 June 2002 with, ‘We have passed this information on to the engineers who have been working on that issue.”

Categories: News