Tuesday Jun 02, 2009

Secure Programming Tips... outdated? Nah...

In support of Scott Rotondo's presentation on Secure Programming today at Community One, I decided to brush up an internal paper on Secure Programming tips and make it available on the OpenSolaris website.

Even though I thought the paper contained some valuable advice, I had some reservations publishing the paper since it was written back in 2002, with examples that were "hot" at the time, but maybe less inspiring today. After all, this was seven year old stuff which is almost eons in a field of work that changes as fast as computer security does, right? I mean, who wants to hear about preventing buffer overflows, heap overflows, integer under- or overruns, sign extension errors, when today people care about XSS-attacks, password-resets and other forms of hacks... We've been there, done that, right?

Well, no... I was flabbergasted to see the list of errors that were fixed by Apple's QuickTime update that was released this month... from Zero Day's webpost, I learned these bugs were fixed:

  • CVE-2009-0188: A memory corruption issue exists in QuickTime’s handling of Sorenson 3 video files. This may lead to an unexpected application termination or arbitrary code execution.
  • CVE-2009-0951: A heap buffer overflow exists in the handling of FLC compression files. Opening a maliciously crafted FLC compression file may lead to an unexpected application termination or arbitrary code execution.
  • CVE-2009-0952: A buffer overflow may occur while processing a compressed PSD image. Opening a maliciously crafted compressed PSD file may lead to an unexpected application termination or arbitrary code execution.
  • CVE-2009-0010: An integer underflow in QuickTime’s handling of PICT may result in a heap buffer overflow. Opening a maliciously crafted PICT file may lead to an unexpected application termination or arbitrary code execution.
  • CVE-2009-0953: A heap buffer overflow exists in QuickTime’s handling of PICT images. Opening a maliciously crafted PICT file may lead to an unexpected application termination or arbitrary code execution.
  • CVE-2009-0954: A heap buffer overflow exists in QuickTime’s handling of Clipping Region (CRGN) atom types in a movie file. Opening a maliciously crafted movie file may lead to an unexpected application termination or arbitrary code execution.
  • CVE-2009-0185: A heap buffer overflow exists in the handling of MS ADPCM encoded audio data. Viewing a maliciously crafted movie file may lead to an unexpected application termination or arbitrary code execution.
  • CVE-2009-0955: A sign extension issue exists in QuickTime’s handling of image description atoms. Opening a maliciously crafted Apple video file may lead to an unexpected application termination or arbitrary code execution.
  • CVE-2009-0956: An uninitialized memory access issue exists in QuickTime’s handling of movie files. Viewing a movie file with a zero user data atom size may lead to an unexpected application termination or arbitrary code execution.
  • CVE-2009-0957: A heap buffer overflow exists in QuickTime’s handling of JP2 images. Viewing a maliciously crafted JP2 image may lead to an unexpected application termination or arbitrary code execution.

This is an amazing list of basic programming errors (worst of all: "blindly trusting untrusted input") that should simply not be allowed to exist anymore (yeah I know, wishful thinking).

In any case, even though the paper is only a guideline and definitely not a complete programming resource, I now no longer have any reservations publishing this brushed-up paper... Thanks Apple!

PS: This, once again strengthens, my believe that browsers (and plug-ins, and media-players) should be run in a tightly controlled environment (no stack execute permission, no heap execute permission, no file access permission outside a controlled part of the file-system)... can anyone spell FGAP? I should really get around to implement some jailing like that using FGAP and not having to worry about Microsoft quietly installing .NET plugins for Firefox anymore.

Tuesday Jan 27, 2009

Dutch OpenSolaris UserGroup gathering.. no. 7... again!

On February 26th, the seventh Dutch OpenSolaris UserGroup meeting will take place. This time the meeting focuses on "OpenSolaris in Practice".

19:00Welcome with pea soup and rye-bread
19:30Update on NLOSUG
Bart Muijzer - Operating Systems Ambassador and NLOSUG host
SUN Microsystems
19:45ZFS Scalable Enterprise Disk Storage
Jacco van Achterberg Inprove IT Infrastructurew Solutions
20:30BREAK with CACert Assurance Party
20:45Practical Uses of OpenSolaris
Rudi van Drunen - Sr. UNIX Consultant and Architect
21:30Closing, with snacks and drinks

This meeting will be hosted by CompetaIT:
Verrijn Stuartlaan 20
2288 EL Rijswijk (ZH)

Seating is limited, so if you intend to join, please register here

Friday Jun 01, 2007

My killer application for branded zones

I finally found an app that will let me have a branded zone booted at all times: Google Earth.

Works (mostly) out of the box. I had to step down the graphics ("use safe graphics") in order for it to render well, but that's all. I'm seriously impressed that this works so well being "ssh -X"ed into the Branded zone... kuddos to the folks who made this work!

an image

And man, do I like the view from this restaurant.. ;-)

Tuesday May 01, 2007

Third NLOSUG meeting on Thursday May 3rd

Announcing NLOSUG, the Dutch OpenSolaris User Group Third Meeting

This meeting is sponsored by SNOW Unix Specialists[1]

For the first time, we provide dial-in access to the UserGroup meeting. See [2] for dial-in details.

When May 3, 2007, 19:00-22:00
Where Zalencentrum Waardenburg
Regterweistraat 5-7
4181 CE Waardenburg
Register http://www.nlosug.org

On Thursday May 3d, 2007, the Dutch OpenSolaris User Group will hold its third meeting at Zalencentrum Waardenburg in Waardenburg. Solaris developers, users, enthusiasts,experts and novices are all welcome.

Theme for this meeting is: Network Virtualisation with Crossbow.

We will start at 19:30, agenda as follows:

  • Bart Muijzer, NLOSUG host, will give an update on the group, share some ideas of where it's going, and lead a group discussion.
  • A Project Crossbow Core Team member will introduce SUNs upcoming solutions on Network Virtualisation and share deep technical details on the OpenSolaris Crossbow project[3].
  • life discussions and Q&A.

Of course there will be plenty of time for socializing and networking, and we'll have food and drinks on hand.

We plan to end around 22:00 with food and drinks at the bar.

Please register at: http://www.nlosug.org/ .

We hope to see you all on May 3d!

[1] http://www.snow.nl/
[2] http://www.nlosug.org/
[3] http://opensolaris.org/os/project/crossbow/

Tuesday Jun 14, 2005

OpenSolaris' security potpourri

Todays release of OpenSolaris will hopefully invite many of you out there to contribute your own code or have it available on OpenSolaris as well as on the other platforms you live on. To help you do so securely, I'll mention a potpourri of OpenSolaris features that we think help to make your code more secure.

Introduction of O_NOFOLLOW and O_NOLINKS

In Solaris 10, and thus now in OpenSolaris, we introduced two new flags to open(2) with the following description:

O_NOFOLLOW If the path names a symbolic link, open() fails and sets errno to ELOOP.
O_NOLINKS If the link count of the named file is greater than 1, open() fails and sets errno to EMLINK.

While O_NOFOLLOW certainly isn't new to UNIX, the addition of O_NOLINKS is. With these two flags, constructs like the open/stat-dance we used previously should become something of the past. In pseudo-code we did something like

	if (lstat(fname, &lsb) == -1) {
		fd = open(fname, O_CREAT|O_EXCL|O_WRONLY, 0600);
		if (fd == -1 && errno == EEXIST) {
			/\* start afresh \*/
	} else if (S_ISLNK(lsb.st_mode)) {
		/\* fail, symbolic link \*/
	} else {
		if ((fd = open(fname, O_WRONLY)) != -1) {
			if (fstat(fd, &fsb) != -1) {
				if (fsb.st_nlink > 1)
					/\* fail, too many links \*/
				else if (fsb.st_dev != lsb.st_dev ||
			 	    fsb.st_ino != lsb.st_ino) {
					/\* fail, file changed after lstat \*/
		/\* success \*/

Now, we can do

	fd = open(fname, O_CREAT|O_NOFOLLOW|O_NOLINKS, 0600);

Of course, if you want to make sure that you don't open any special files (devices), you'll still have to lstat()/fstat() and check for S_ISREG(). I hoped to introduce O_REGULAR too, but that didn't make it (yet? :-).

Non-executable stacks

Not new to Solaris, but maybe new to you, and certainly worth pointing out: large parts of Solaris, at least the commands in ON (the Operating System and Networking part of Solaris) are built with the stack-segment mapped as non-executable memory. Of course, this will not stop people from exploiting stack-overflows, but it'll surely make it harder to do.

Check out the definition of NES_MAPFILE in usr/src/cmd/Makefile.cmd. It defines an option passed to the linker (through the C-compiler front-end) that tells it to use a mapfile (mapfile_noexstk) that contains

stack = STACK ?RW;

This line is a segment declaration that tells the runtime linker to create the applications stack segment with the Read and Write flags enabled, but the eXecute flag unset. You can check which flags for the stack segment of a particular binary are set by running elfdump(1) on the binary. Search for an ELF section of type PT_SUNWSTACK, as in

$ elfdump /bin/ls 

ELF Header
  ei_magic:   { 0x7f, E, L, F }
  ei_class:   ELFCLASS32          ei_data:      ELFDATA2MSB
  e_machine:  EM_SPARC            e_version:    EV_CURRENT
  e_type:     ET_EXEC
  e_flags:                     0
  e_entry:               0x10e48  e_ehsize:     52  e_shstrndx:   21
  e_shoff:                0x6718  e_shentsize:  40  e_shnum:      23
  e_phoff:                  0x34  e_phentsize:  32  e_phnum:       6

Program Header[0]:
    p_vaddr:      0x10034         p_flags:    [ PF_X  PF_R ]
    p_paddr:      0               p_type:     [ PT_PHDR ]
    p_filesz:     0xc0            p_memsz:    0xc0
    p_offset:     0x34            p_align:    0
Program Header[5]:
    p_vaddr:      0               p_flags:    [ PF_W  PF_R ]
    p_paddr:      0               p_type:     [ PT_SUNWSTACK ]
    p_filesz:     0               p_memsz:    0
    p_offset:     0               p_align:    0

As shown here, the stack segment of /bin/ls is mapped with the PF_W and PF_R, and not with PF_X. Some example mapfiles can be found in /usr/lib/ld, like /usr/lib/ld/map.noexdata, which shows how to map data-segments without the executable bit set (for use on x86 machines). More info on mapfiles (and the linker in general) can be found in the Software Developer Collection on docs.sun.com.

lint security checking

If you've looked at the Makefiles in OpenSolaris, you may have encountered the -errsecurity flag that is passed on to lint. Specifying this flag makes lint perform several static checks on your code that helps keeping you (me?) alert when coding. It won't of course fix any of the logic bugs that are present, but it'll alert you when you use one of the known insecure functions that are part of any POSIX-like UNIX.

There are three levels of complaining that lint will perform for you, core, standard and extended. By default, the Solaris Makefiles set this to "core" which include these checks

  • Use of variable format strings with the printf() and scanf() family of functions
  • Use of unbounded string (%s) formats in scanf() functions
  • Use of functions with no safe usage: gets(), cftime(), ascftime(), creat()
  • Incorrect use of open() with O_CREAT

New code to Solaris should not introduce any new lint-warnings on the core level, but I'd suggest you run it with standard or extended on any code you change or introduce. For more info on this option, see section 5.3.13 of the lint Source Code Checker.

Least privilege

Glenn Brunette already showed an example of how to convert an existing setuid application (ping) into a privilege-aware application. There is more information on how to develop privilege aware applications in the Solaris Security for Developers Guide, but I thought I'd just show a little bit of one of the privilege-aware daemons, the NFS daemon nfsd.

Right after starting up, the NFS daemon uses its initial privileges to create a lockfile in a root-owned directory (_create_daemon_lock). It needs all privileges to do so, since it modifies an object owned by "root".

All that it needs from now on, is the privilege to bind to a reserved port (the nfs-port); nothing more, nothing less. Thus the call to __init_daemon_priv which is a convenience routine around a number of calls to setppriv() and setreuid() and setgid().

Once this routine returns, the daemon runs with just the privilege of a normal process (>tt>basic) augmented with the privilege to bind to the NFS port (sys_nfs). No more special "root" like privileges from this point on. In this way, we can perform the argument parsing and other initialization code using minimized privileges that limit the impact of a possible bug in the start-up code.

After the daemon has registered itself for the various protocols it is supposed to support (calls to do_one and do_one), it relinquishes even more privileges. For example, It gives up its right to fork(2) and exec(2) other binaries. For this it uses another convenience rapper-function called __fini_daemon_priv() which removes the listed privileges from the set of permitted privileges (which also removes them from the effective set).

When this routine completes, the nfs daemon runs with the following set of privileges:

# ppriv -v `pgrep nfsd`
5239:   /export/ws/work/usr/src/cmd/fs.d/nfs/nfsd/nfsd
flags = PRIV_AWARE
        E: sys_nfs
        I: none
        P: sys_nfs
        L: none

So, IF someone would be able exploit, e.g., a stack overflow bug in nfsd, it the exploit code would not only run as (daemon, daemon) without any basic privilege, it would also need to run in the address space of the daemon itself since it can't fork() nor exec().

Makes for a pretty useless target to attack, not?

Technorati Tag:
Technorati Tag:

Monday Jun 06, 2005

First Post

Hello World,

Since I will come out of the shadows of our SCCS history one day real soon now I might do a proper introduction as well... So: Hi! I'm Joep Vesseur. I'm a staff engineer at the Solaris Security and Networking Technologies group where I've been working since I joined Sun in 2000.

I'm based in the Netherlands and share--a rather nice, for a change-- office with Casper Dik, the man who posts more than he should.

Before working for Sun I worked as a researcher at the Computer Crime department of the Forensic Science Laboratories and as a developer at the Computer and Network Group at the University of Amsterdam.

My roots lie in the area of Parallel Scientific Computing, but I was mostly interested in the the "Parallel Computing" part. I've had quite a lot of fun on the institutes 512-node Parsytec GCel which looked quite sexy for its time (1994) (and no, that's not me in the picture). I also spent some time at Parsytecs' Chemnitz office developing parts of their OS for the Parsytec CC (PowerPC based platform). Interesting times...

At Sun, I largely focus on all things PAM which I hope to tell more about once OpenSolaris has set sail. Till then!




  • General
« December 2016