Friday Jan 04, 2008

UPDATED: Solaris - Now With More Fuzz

Every six months or so, I try to do a run of my fuzz tests against the Solaris OS. The first test was conducted a year ago with build 42 followed by a test during our summer break on build 68 of Nevada. It should come as no shock then that I conducted another test during the winter break on build 80.

The tools and methodology are the same (although there are still some kinks to be worked out to make it fully automated), but for those who have not read my earlier post, I will summarize. The tests were conducted on a fresh installation of Nevada build 80 built with the SUNWXCall (Entire + OEM) installation cluster. A sparse-root, non-global zone (called "fuzz") was created for the tests and the software was loaded into the zone. Next, the names of all of the ELF binaries were collected, using the make-exec-list script run from within in the non-global zone. Next, the make-fuzz-tests script was run to generate the 36 different fuzz files to be used as input for each binary tested. Lastly, the test was kicked off using the exec-fuzz-tests script. The script pretty much runs unattended except when I need to kill off runaway processes. I still need to add some code to kill off anything started at the end of each test so you do not end up with tons of extra processes running and consuming memory.

At any rate, the test run completed and I have posted my results in Bugster and the bugs are also available in the OpenSolaris Bug Database Search using the keyword fuzz. The programs impacted can be viewed using this query.

While I tend to do this kind of work for fun as a holiday distraction, it does have real benefit. Programs that fail during a fuzz test (usually core dumping although a runaway or two have also been found) fail due to unvalidated input that leads to a buffer overflow or arithmetic exception of some kind. Input validation is not to be taken lightly and should be performed by every program and service. In fact, on the CERT Top 10 Secure Coding Practices list, validate input is item #1 and with good reason.

Take care,

Glenn

Technorati Tag:

Friday Nov 02, 2007

NEW: Solaris Package Companion v0.7

This one must have slipped my mind. Please accept my apologies. Back in September (2007), I published an updated version of the Solaris Package Companion. For those not familiar with the tool, here is a brief overview:

   The Solaris Package Companion is a small Korn shell script that allows you to ask
   quite a number of interesting questions about the relationships between Solaris 
   metaclusters, clusters and packages as well as their respective dependencies. Very
   often, answers to these kinds of questions are essential for the construction of 
   minimized systems as well as more generally for OS golden images.

   The goal of the Solaris Package Companion, or SPC for short, is to do all of the 
   hard work so you don't have to. SPC will create a cache of important facts by mining
   information from the various packaging files and directories to allow you to quickly 
   and easily obtain answers to a variety of questions such as:

     \* What clusters or packages are contained in a given metacluster?
     \* What packages are contained in a given cluster?
     \* What metacluster or cluster contains a given package?
     \* On what other packages does a given package or cluster depend?
     \* Which packages depend on a given package?
     \* … and so on…

New to this release is the tag before the item description to inform the user of the type of object being dispayed. [P] indicates a package while [C] is a cluster and [M] is a metacluster. Another new feature is the ability to fold packages back into their respective clusters (where possible). This can be helpful when trying to create a complete list of items for a standard OE image or JumpStart configuration. Essentially, this will report the cluster name in which the package is found. This can be accomplished using the -F (folding) option. The new -Z option will display the list of packages that depend on a specific cluster. There is also an new experimental option -f that will allow you to map a file to a package or cluster (with the -F option). This only works for local files reliably right now. Finally, special thanks to Dave Comay for reporting a bug - that has been fixed in this version too!

You can find more information, examples and the source code on the project page.

Technorati Tag:

NEW: Solaris 10 Set-ID and World Writable Overview

Various organizations have often asked for more detail regarding the set-uid, set-gid and world writable programs that are shipped by the default in the Solaris OS. Well, the wait is over (at least for Solaris 10 8/07)!

Today, I am happy to announce the public release of an overview document that describes these file system objects in detail. This document is still a draft and could still needs to answer a few questions, but I believe that it is far enough along to open up the discussion and begin getting feedback from all of you! If you are interested and want a copy of the document, you can find it here. Looking forward to your comments!

From the document:

While there are often many files delivered by operating systems and other software products, organizations are often most concerned with those programs and services that have or run with special privilege. Unfortunately, there is at times a lack of information regarding what these programs do and why their privileges are necessary. The goal of this document is to provide additional information on four special classes of objects delivered by the Solaris OS: Set-UID Files, Set-GID Files, and World Writable Directories and Files. With this information, organizations will be able to better understand the privileged programs, directories and files that exist on their systems.

If you would like to make recommendations or even implement an improvement (such as one of the RFEs listed in the document), please consider joining the OpenSolaris Security Community!

Glenn

Technorati Tag:

NEW: Solaris 10 Security Best Practices

It is with great pleasure that I can (albeit belatedly) announce the arrival of the latest security guidance from both Sun and the Center for Internet Security. Working together, in concert with representatives from academia, industry and government, we have published security guidance for Solaris 10 11/06 and 8/07. This content represents the best and most complete form of Solaris security guidance ever produced.

Not only are the recommendations based upon industry consensus but they are also supported by Sun. What is even better is that this material was completed with support and feedback from both the National Security Agency and the Defence Information Systems Agency. I would like to especially thank both organizations for their significant contributions to this material! This iteration brings us (Sun, CIS, NSA and DISA) closer than even toward a single, consistent set of security recommendations for the Solaris OS.

The Benchmark itself has been restructured. Today, it comes in the form of two documents: (1) the core hardening Benchmark itself and (2) an extended appendix covering additional Solaris security controls with examples and references for more information. Further, the Benchmark itself has been significantly reorganized to improve its correctness and flow. Thanks to Carole, our editor!

Some new elements to the Benchmark include headers for each item that tell you if a given recommendation is a Solaris 10 default value, for what platforms it applies and even what configuration settings you need to implement the recommendation using the Solaris Security Toolkit. Overall the document is a tremendous step forward toward bringing the world the best available insight into how to harden and more generally secure their Solaris systems. There have also been quite a few updates to account for changes and enhancements in Solaris. The Solaris Security Appendix document is completely new and provides an overview of the security capabilities of the Solaris OS with many examples and references for more information including step-by-step BluePrints and HOWTOS. If you are responsible for managing or securing a Solaris 10 system, these documents are for you!

You can find a copy of these documents at both the CIS web site as well as on OpenSolaris.org (CIS Solaris Benchmark, Solaris Security Appendix). As always, feedback and ideas for future revisions are encouraged! If you are interested in participating in future versions of these documents, please consider joining the CIS Unix Benchmark Team. Contact Dave for more information!

Glenn

Technorati Tag:

Monday Aug 13, 2007

Solaris Fingerprint Companion v0.5

For some reason, the links to things on SunSolve like the Solaris Fingerprint Database have changed and as a result, tools like my Solaris Fingerprint Companion stopped working. I would like to publicly thank Richard Mayebo for being the first to let me know of this issue. In addition to just fixing the links, it felt like an excellent opportunity to re-test the tool with the latest versions of Perl shipping on both Nevada as well as Ubuntu. I am very happy to report that the Solaris Fingerprint Database Companion tool continues to work just fine (after the required add-ons are installed). I have posted the latest and greatest version here as part of the OpenSolaris Security Community.

Give it a try and let me know what you think!

Take care,

Glenn

Technorati Tag:

Wednesday Aug 01, 2007

Solaris Non-Executable Stack Concluded

Since publishing my two part series on non-executable stacks in the Solaris operating system, I received some very useful feedback and clarifications that I wanted to share with everyone. First, Vladimir Kotal commented on my first article that:

Having to grep(1) for the CPU features is really clumsy. Maybe psrinfo(1M) could be extended to print them out? (for every (virtual) CPU present in the system)

Frankly, I agree. After asking around however, today there does not appear to be a cleaner interface (although there is a bunch of discussion around adding one). Sherry Moore and Joe Bonasera were kind enough to point out that there is a programmatic way to access this information in the form of cpuid(7d). Joe also shared the following with me that you may find interesting:

The NX information doesn't belong in isainfo. isainfo, I'm told, is only meant to reflect processor capability information that is directly usable from user mode.

The NX bit feature has to do with page table construction which is not something you do from userland. What's a more interesting thing to know is "Does not specifying PROT_EXEC have any effect on this system, or is PROT_EXEC implicit for all PROT_READ segments?" Even cpuid doesn't help with that information as various bits of the OS memory subsystems might do different things along the way. For example if for some reason you're running a non-PAE 32 bit kernel, even though cpuid says that NX is supported, NX bits wont be used.

A similar issue has come up in the Open Solaris Xen project, in that many people want to know if their processor supports AMD-V or Intel VT-x. That information comes from CPUID, but is only usable from supervisor (either kernel or hypervisor) code, hence we haven't added it to isainfo. But it is a valid question to ask if the cpu/bios you have would support running such software w/o actually having it.

That said, Sherry did clue me in on a program called cpuid which can allow us to get this information and a lot more (subject to the issues noted by Joe above). Unfortunately, the cpuid program was developed for Linux and will not compile by default on Solaris:

blackhole$ gmake
cc -g -Wall -Wshadow -Wcast-align -Wredundant-decls -Wbad-function-cast -Wcast-qual -Wwrite-strings -Waggregate-return 
-Wstrict-prototypes -Wmissing-prototypes -D_FILE_OFFSET_BITS=64 -DVERSION=20070801 -o cpuid cpuid.c
cpuid.c:26:25: linux/major.h: No such file or directory
cpuid.c: In function `explain_errno':
cpuid.c:3191: error: `CPUID_MAJOR' undeclared (first use in this function)
cpuid.c:3191: error: (Each undeclared identifier is reported only once
cpuid.c:3191: error: for each function it appears in.)
cpuid.c: In function `real_setup':
cpuid.c:3472: warning: implicit declaration of function `makedev'
cpuid.c:3472: error: `CPUID_MAJOR' undeclared (first use in this function)
cpuid.c: In function `main':
cpuid.c:3751: warning: initialization discards qualifiers from pointer target type
cpuid.c:3752: warning: initialization discards qualifiers from pointer target type
cpuid.c:3753: warning: initialization discards qualifiers from pointer target type
cpuid.c:3754: warning: initialization discards qualifiers from pointer target type
cpuid.c:3755: warning: initialization discards qualifiers from pointer target type
cpuid.c:3756: warning: initialization discards qualifiers from pointer target type
cpuid.c:3757: warning: initialization discards qualifiers from pointer target type
gmake: \*\*\* [cpuid] Error 1

Luckily, the changes to get this program to work on Solaris were simple (Thanks Sherry!). All that we needed to do was remove the references to /dev/cpu/\* as that is a Linux-ism that does not exist on Solaris. Here is the complete diff for those wanting to try this at home:

blackhole$ diff linux-cpuid.c cpuid.c
25a26
> #if 0
26a28
> #endif
3188a3191
> #if 0
3194a3198
> #endif
3450a3455
> #if 0
3489a3495
> #endif

Clearly, if you wanted the program to work on either OS, you could just substitute the #if 0 strings for something like #if !defined(SOLARIS) and then just define SOLARIS in the CFLAGS parameter when compiling on Solaris. But I digress... With this simple change implemented, you can now compile the cpuid program on Solaris:

blackhole$ gmake
cc -g -Wall -Wshadow -Wcast-align -Wredundant-decls -Wbad-function-cast -Wcast-qual -Wwrite-strings -Waggregate-return 
-Wstrict-prototypes -Wmissing-prototypes -D_FILE_OFFSET_BITS=64 -DVERSION=20070801 -o cpuid cpuid.c
cpuid.c: In function `main':
cpuid.c:3757: warning: initialization discards qualifiers from pointer target type
cpuid.c:3758: warning: initialization discards qualifiers from pointer target type
cpuid.c:3759: warning: initialization discards qualifiers from pointer target type
cpuid.c:3760: warning: initialization discards qualifiers from pointer target type
cpuid.c:3761: warning: initialization discards qualifiers from pointer target type
cpuid.c:3762: warning: initialization discards qualifiers from pointer target type
cpuid.c:3763: warning: initialization discards qualifiers from pointer target type
gzip < cpuid.man > cpuid.man.gz

These warnings can be safely ignored. With the program now compiled, let's give it a try and see what it can tell us about the NX bit:

blackhole$ ./cpuid | grep exec
      execution disable                      = false

Interesting. This system does not have the NX capability likely because I am running (Nevada in this case) in a Parallels VM which is 32-bit (reference Joe's note above). Let's give this a better test subject by trying it on a Sun X2100. This command is run from the global zone of a system running Solaris 10 11/06:

$ ./cpuid | grep exec
      no-execute page protection            = true

Careful observation will also show the AMD and Intel naming differences that I had talked about previously with respect to XD and NX.

Well, I think that I have talked about this subject to death. I hope that you found it interesting and perhaps a little educational. As always, I love to get your feedback! Before signing off, once again I would like to thank Sherry Moore and Joe Bonasera for sharing their knowledge and experience with me (and thereby with you)!

Take care,

Glenn

Technorati Tag:

Monday Jul 30, 2007

Interesting File Discovery Tool version 0.5

As promised, I have uploaded version 0.5 of the Interesting File Discovery Tool (or ifd for short). This update includes fixes and enhancements that were contributed by Perley and Joe Moore. Thank you both for your contributions!

The biggest change in this version is the introduction of the -D parameter which enables you to change the program used to calculate the file digests (or fingerprints):

# ./ifd-v0.5.sh -h

   ./ifd-v0.5.sh - Interesting File Discovery Tool

   ifd -[ugnw] [-ds] [-q] [-D cmd] { -c | -l | [Solaris Product Directory] }

      -c     Collect information from /var/sadm/install/contents
      -d     Calculate MD5 digest for each file (Solaris 10 only)
      -D     Command used to calculate file fingerprint
      -g     Print information on files with the set-gid bit set
      -h     Display this message
      -l     Collect information from /var/sadm/pkg
      -n     Print information on WW directories without sticky bit set
      -q     Quiet mode.  Do not print headers.
      -s     Validate ELF file signature for each file (Solaris 10 only)
      -u     Print information on files with the set-uid bit set
      -w     Print information on world writable files and directories
      -?     Display this message

This can be useful in cases where you are running the tool on earlier releases of Solaris that do not have the integrated digest command or in cases where you want to use a different algorithm. For example, with this change, you could tell ifd to create SHA-512 fingerprints:

# ./ifd-v0.5.sh -c -D "/usr/bin/digest -a sha512" -d -u

Set-UID Programs

SUNWaccu 4755 root adm 29478dd7ebde1555eaef0987789094cc778794ee73ddcfb0a67c44004f93652f599dd7276342f8113cc4e58f877e883b4687c4ca0f30f0585dd725ddaffeb0b7 /usr/lib/acct/accton
SUNWbip 4555 root bin 95c814f7ff9606e0dc8818b51dacf74e92e5b3af329d66dc6fc8343c20ae741c1cea758568a318713ce6aacb35d1605bd6ee0911cdd2457aa85ceed363d17326 /usr/sbin/ping
SUNWbnuu 4511 root uucp 540f94a7054233498f1925aceef3c69b76300141ef38acc920ae005287db5546a03daef37c19b98149e11a26c7b4da137788e45cf642a3449345f635d8dbf762 /usr/bin/ct
SUNWbnuu 4511 uucp uucp 1754a7f7aaea60f4a1d1ca1915af30bc0157333061c096088bd3b719d008167f603380fae5b417a237cc9fe8c4cdcf524b22c61a471d0a06df5188cabedb475c /usr/bin/uuglist
[...]

Pretty neat. Thanks again to Perley and Joe for their feedback and support! To everyone - give this new version a shot and let me know what you think.

Take care,

Glenn

Technorati Tag:

Wednesday Jul 25, 2007

Solaris Non-Executable Stack Continued

Previously, we covered some of the history and basics of Solaris non-executable stacks and how they can be enabled globally on both SPARC and x86/x64 systems. In this article, we extend that foundation by talking about how developers can configure their own programs to have non-executable stacks, regardless of the value of the global system setting, noexec_user_stack.

This little bit of magic is accomplished through the use of a linker map file. In the case of non-executable stacks, the linker map file in question is /usr/lib/ld/map.noexstk. Simply specifying this map file during a compilation or link will cause the resulting program to have a non-executable stack. Looking at the comments in this file, we see how this is accomplished:

#
#ident  "@(#)mapfile_noexstk    1.3     01/07/13 SMI"
#
# Copyright (c) 2001 by Sun Microsystems, Inc.
# All rights reserved.
#
# Linker mapfile to create a non-executable stack definition within an
# executable.
# The linker does not use this file automatically, so one must use the -M 
# option to cc or ld:
#
#       cc -M /usr/lib/ld/map.noexstk myprogram.c
#
stack = STACK ?RW;

If this sounds pretty straightforward and easy to use, that is because it is! Let's go ahead and give it a try! Before we begin, I would like to thank Scott Rotondo for sharing with me the following sample program. This program will attempt to execute code on the stack. Our test system is configured with noexec_user_stack=0 and we will compile our test program both with and without using the map file so that they can be compared with one another.

First, here is our test program:

#include 
#include 

int x = 0;

void
incr(void)
{
        x++;
}

typedef void (\*funcptr)(void);

int
main(int argc, char \*\*argv)
{
        funcptr f;
        char code[100];

        /\* Copy the incr() function to the stack. \*/
        memcpy(code, (void \*)incr, sizeof(code));
        f = (funcptr)code;

        /\*
         \* Increment x twice, once by calling incr() and
         \* once by running the copy on the stack.
         \*/
        printf("x = %d\\n", x);
        incr();
        printf("x = %d\\n", x);
        f();
        printf("x = %d\\n", x);
        return (0);
}

Now, let's compile the program (with and without the map.noexstk map file):

$ gcc -O -o incr incr.c
$ gcc -O -o incr-nx -Wl,-M,/usr/lib/ld/map.noexstk incr.c

(Thank you to Luke for pointing out a cleaner way to pass the linker map file using gcc!)

Note that if you were using the Sun C compiler, you could have used the following commands:

$ cc -O -o incr incr.c
$ cc -O -o incr-nx -M /usr/lib/ld/map.noexstk incr.c

So, how do we know that the program, incr-nx, has a non-executable stack? One of the easiest ways is to use the elfdump(1) command telling it to look for the program header type, PT_SUNWSTACK. The absence of this program header means that the program is effectively in a default configuration where (depending on the platform) the stack segment could be readable, writable as well as executable. If a PT_SUNWSTACK program header is found then the default is not being used, and we need only to look at the p_flags parameter to see what permissions are being assigned to the stack segment.

$ elfdump -p -N PT_SUNWSTACK incr
$ elfdump -p -N PT_SUNWSTACK incr-nx

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 you can see from the output of the two commands above, the incr program's stack segment is configured in the default manner and will therefore have an executable stack (unless of course the global system parameter noexec_user_stack is set to 1). On the other hand, the incr-nx program does have a PT_SUNWSTACK program header. Looking at the p_flags parameter, we see that this program's stack segment will have only the read (PF_R) and write (PF_W) flags enabled.

The next obvious question is whether these programs will behave differently. Certainly, we would expect them to given that they are configured to execute code on the stack yet such an operation is only permitted in one of the two programs. Let's take a closer look:

$ ./incr
x = 0
x = 1
x = 2
$ ./incr-nx
x = 0
x = 1
Segmentation Fault (core dumped)

If we had enabled logging of attempts to execute code on the stack using the noexec_user_stack_log parameter, we would have also seen a syslog message similar to:

$ tail -1 /var/adm/debug
Jul 25 22:11:36 quasar genunix: [ID 533030 kern.notice] NOTICE: incr-nx[12553] attempt to execute code on stack by uid 101

Pretty cool, eh? So with the simple addition of the linker map file, we can now deploy programs and services that will have non-executable stack segments (out of the box)! In fact, a large portion of the ON (operating system and networking) consolidation in the Solaris OS is already configured this way! In fact, even the Sun-contributed Firefox (that is also included in Solaris 10 and OpenSolaris) uses this mechanism to enable non-executable stacks. Yes, even OpenOffice/StarOffice and Xorg are in on the action! So, what are you waiting for? Give it a try today!

I hope you enjoyed this brief overview into Solaris non-executable stacks. As always, I would love to get your feedback and ideas. You can read more on this topic here and here.

Take care,

Glenn

Technorati Tag:

Solaris Non-Executable Stack Overview

The ability to configure a Solaris system to run with non-executable stacks is not overly new. That functionality was originally introduced into the Solaris 2.6 operating system with the noexec_user_stack kernel parameter. Looking at the source code, this is how this parameter was documented (in usr/src/uts/common/vm/seg_vn.c):

 207 /\* 
 208  \* Patching this variable to non-zero allows the system to run with 
 209  \* stacks marked as "not executable".  It's a bit of a kludge, but is 
 210  \* provided as a tweakable for platforms that export those ABIs 
 211  \* (e.g. sparc V8) that have executable stacks enabled by default. 
 212  \* There are also some restrictions for platforms that don't actually 
 213  \* implement 'noexec' protections. 
 214  \* 
 215  \* Once enabled, the system is (therefore) unable to provide a fully 
 216  \* ABI-compliant execution environment, though practically speaking, 
 217  \* most everything works.  The exceptions are generally some interpreters 
 218  \* and debuggers that create executable code on the stack and jump 
 219  \* into it (without explicitly mprotecting the address range to include 
 220  \* PROT_EXEC). 
 221  \* 
 222  \* One important class of applications that are disabled are those 
 223  \* that have been transformed into malicious agents using one of the 
 224  \* numerous "buffer overflow" attacks.  See 4007890. 
 225  \*/ 

While non-executable stacks provide are a very useful technique for thwarting certain kinds of buffer overflow attacks, it should be noted that there exist other attack methods that do not rely on executable stacks. One such method was discussed back in 1999 on Bugtraq, but even in this case the author noted that there was inherent value in non-executable stacks (if only as an additional defense in depth layer):

Hopefully, these exploits demonstrate that it is important to make sure that programs that run at an elevated privilege are free of buffer overflow bugs. The stack protection will certainly help protect you from the majority of intruders, but moderately competent intruders will probably be able to bypass it.

Just as with minimization, hardening, and the deployment of services with reduced privilege, non-executable stacks are just another layer or tool to be used as part of a more comprehensive security architecture. But anyway, back to our story...

As with other kernel parameters, the non-executable stack state can be be adjusted (enabled or disabled) using the /etc/system file. For example, the following statement added to /etc/system would enable this feature:

set noexec_user_stack=1

As noted in the inline documentation above, experience has shown that "most everything works". In fact, the recommendation to enable this feature has been in Sun BluePrints since 1999 and similarly in the Solaris Security Toolkit since its inception. Looking even further, you find this common recommendation across the industry.

As a companion to this parameter, the noexec_user_stack_log parameter could be used to enable logging when this feature (if enabled) detected an attempt to run code from the stack. By default, this parameter is enabled if the noexec_user_stack parameter is enabled so no further action is required unless of course you want to prevent such logging. That has not stopped authors of tools and articles from recommending to enable it anyway using the command:

set noexec_user_stack_log=1

When this parameter is enabled and there is an attempt to execute code on the stack, a message such as the following will be generated and delivered via syslog to kern.notice:

Jul 25 14:48:02 quasar genunix: [ID 533030 kern.notice] NOTICE: myprog[12289] attempt to execute code on stack by uid 101

In this way, a system administrator can detect such attempts and take appropriate action.

Back in the days of Solaris 2.6, this parameter really only applied to the SPARC platform. Years passed and this feature continued to be available in Solaris 7, Solaris 8 and so on. As good fortune would have it, Intel and AMD got on board with the idea and the NX Bit was born. Technically speaking, Intel refers to its implementation as the XD Bit (for Execute Disable) while AMD has used the term NX (for No Execute), but for the purposes of Sun's implementation and this article, we will consistently use the term "NX" to refer to this functionality.

To find out if your system supports the NX bit, you can check in with the dmesg(1M) command:

$ dmesg | grep features
Jun 28 11:00:05 sec1 unix: [ID 126719 kern.info] features: 1176fdf<cpuid,cmp,sse3,nx,asysc,sse2,sse,pat,cx8,pae,mca,mmx,cmov,pge,mtrr,msr,tsc,lgpg>

Similarly, if you have syslog configured to log kernel.info messages, you can also get the information from your system log files:

$ grep "features:" /var/adm/debug
Jul 19 16:43:06 quasar unix: [ID 126719 kern.info] features: 1076fff<cpuid,sse3,nx,asysc,sse2,sse,pat,cx8,pae,mca,mmx,cmov,de,pge,mtrr,msr,tsc,lgpg>

The first example was taken from a SunFire X2100 system whereas the second example was taken from an Ultra 20. The same commands should be able to be used on other x86/x64 systems in order to determine if this CPU feature is available.

On the SPARC platform, the non-executable stack functionality is available but disabled by default (for SPARC V8) in order to support a fully ABI-compliant execution environment. For 64-bit SPARC platforms, however, the SPARC V9 ABI specifies a non-executable stack by default. Note that 32-bit applications running on a 64-bit kernel do not automatically get this protection by default and would rely on the noexec_user_stack parameter being set to 1 for example.

On NX-capable x86/x64 platforms, Solaris OS uses the NX bit by default whenever PROT_EXEC is not specified. Stack segments, however, use PROT_EXEC by default, so the NX functionality must be explicitly enabled on these platforms to provide stack protection. As noted above, this can be globally configured using the noexec_user_stack parameter just as with SPARC-based platforms.

From the product documentation, it should be noted that a system administrator can disable all use of the NX bit (non-SPARC platforms) by using the eeprom(1M) command to set enforce-prot-exec to off. This variable is provided as a transition workaround for any system with legacy applications that are missing PROT_EXEC.

In this article, we have taken a brief look at the history of non-executable stacks in Solaris dating back to the original integration of this functionality in Solaris 2.6 all the way to the present. In the next article, we will talk a little bit about how this functionality can be enabled on a per-file basis in the Solaris 10 OS.

Take care,

Glenn

Technorati Tag:

Monday Jul 23, 2007

Fuzzing around with Nevada

I guess that it is time for another of my pet projects to come to light. For the last seven months or so (on and off), I have been conducting some rudimentary fuzz testing on Solaris Nevada. Initially it started off as my winter (break) project with build 42 and has continued through a few other builds with my most recent being build 68.

For those unfamiliar with the concept, the goal of fuzz testing is to provide random input to programs and see how they behave. The results thus far have been pretty interesting. Many, in fact the vast majority, of programs in Nevada gracefully handled the input and either exited, provided a usage message or did something else equally benign. That said, a good number of programs failed to gracefully cope with the random input. In these cases, the typical response was a core dump although a few programs were triggered to enter an infinite loop - which was quite interesting.

The tests were conducted using code derived from the work published at the University of Wisconsin. In actuality, I only performed one of a handful of tests that they support - stdin fuzz testing. Basically programs are subjected to the equivalent of:

$ program < [file_containing_some_random_input]

I would love to do some of their additional tests as time permits. At any rate, the results are in and to date, a problem has been found with nearly 80 programs. Bug reports have been filed for each and every one and can be tracked using the keyword fuzz at the OpenSolaris Bug Database Search. To see the programs impacted thus far, try this link.

So far, a number of these have been reviewed and accepted and better still several have been already fixed and the changes integrated back into the code base. Even cooler, some of the fixes have been accepted upstream in other open-source projects such as X.org. What a great example of the participation age where the results of a single test in Nevada have helped to improve the quality for every user of that code (regardless of the OS on which that code is run).

Over time, I would love to see more sophisticated tests integrated into the testing process (e.g., command-line argument aware fuzz input testing), but for now this will serve as a start to point us in the right direction.

I would love to know if others have conducted similar tests and how they turned out.

Take care,

Glenn

Technorati Tag:

Interesting File Discovery Tool version 0.4

Way back when, I did a post that introduced the Solaris Interesting File Discovery Tool. Being a fan of automation, I had written the tool mainly for myself, but I was pleasantly surprised to hear that people were happily using it. This leads me to today's posting.

A month or so ago, Fredrich Maney dropped me an e-mail letting me know of his experience running the tool and what tweaks he had made to improve it for his environment. In particular, he wanted to run this tool on Solaris 9. Recognizing that I had screwed up by not making the tool more broadly useable, I decided that an appropriate penance would be for me to not only fix this bug but to also build in a few new enhancements. Today, I am happy to announce the arrival of the Solaris Interesting File Discovery tool version 0.4.

New to this version is:

  • Support for Solaris 9 (and likely 8) in addition to Solaris 10;
  • Support for Solaris ELF signature verification (Solaris 10 only);
  • Support for file fingerprint (MD5) generation (Solaris 10 only);

Yes, I do realize the irony of allowing the tool to run on older versions of the operating system while at the same time adding new features for only Solaris 10 and newer. Unfortunately, the older versions of the operating system simply do not support ELF signatures or the digest(1) command. Hey, these are just a few of the many good reasons why you should consider adopting Solaris 10 today!

Moving on... Let's take it on a brief spin to see what things look like. First, let's check out the options available:

# ./ifd-v0.4.sh -h

   ./ifd-v0.4.sh - Interesting File Discovery Tool

   ifd -[ugnw] [-ds] [-q] { -c | -l | [Solaris Product Directory] }

      -c     Collect information from /var/sadm/install/contents
      -d     Calculate MD5 digest for each file (Solaris 10 only)
      -g     Print information on files with the set-gid bit set
      -h     Display this message
      -l     Collect information from /var/sadm/pkg
      -n     Print information on WW directories without sticky bit set
      -q     Quite mode.  Do not print headers.
      -s     Validate ELF file signature for each file (Solaris 10 only)
      -u     Print information on files with the set-uid bit set
      -w     Print information on world writable files and directories
      -?     Display this message

So, let's fire it up with the works. In this example, we will use the /var/sadm/install/contents file as our source and look for files that are set-uid, set-gid, or world writable (including a special check for world writable directories that do not have their sticky bit set). Keep in mind that you can also point the tool at the /var/sadm/pkg directory as well as a DVD/CD distribution depending on your needs. This allows you to use the tool for a different OS (if you can point it at a mounted DVD for example) or your local system (without a need for a separate OS distribution at all).

For each matching file, we will record:

  • package that installed the file
  • file permissions
  • file owner
  • file group
  • status of ELF signature verification
  • MD5 fingerprint (suitable for using with the Solaris Fingerprint Database)
  • file name

So, without further ado...

# ./ifd-v0.4.sh -c -d -s -u -g -w -n

Set-UID Programs

SUNWaccu        4755   root       adm        PASS   0c003207377f5bd2a9b5be5394205384  /usr/lib/acct/accton
SUNWbip         4555   root       bin        PASS   ff140f86524789942e3fc66867f5be40  /usr/sbin/ping
SUNWbnuu        4511   root       uucp       PASS   6cf336d0ccf51c2b66a241fc615dc2da  /usr/bin/ct
SUNWbnuu        4511   uucp       uucp       PASS   03c7fab44124264943e892ff0f9f318e  /usr/bin/uustat
SUNWbnuu        4511   uucp       uucp       PASS   1491a5a26b6936d3eed53eab01890bcc  /usr/bin/uuglist
SUNWbnuu        4511   uucp       uucp       PASS   453cdc99764045086d813708e268914c  /usr/lib/uucp/uusched
SUNWbnuu        4511   uucp       uucp       PASS   4ad108e11de2ce16cb5a804ee9618589  /usr/lib/uucp/uuxqt
SUNWbnuu        4511   uucp       uucp       PASS   4ca26f335387f825b786fe650001e2a1  /usr/lib/uucp/remote.unknown
SUNWbnuu        4511   uucp       uucp       PASS   65cca9d2de0955d87dc52220da544c14  /usr/bin/uuname
SUNWbnuu        4511   uucp       uucp       PASS   7059dea52454585b825d2fe731bd9ccf  /usr/bin/uucp
SUNWbnuu        4511   uucp       uucp       PASS   784a41f571364cf7dd15d91798494528  /usr/lib/uucp/uucico
SUNWbnuu        4511   uucp       uucp       PASS   bdb1aa92b2169d8774f1ad8aea589aa7  /usr/bin/uux
SUNWbnuu        4511   uucp       uucp       PASS   d6bb0cfc77f20d31c64d3af07044b8f6  /usr/bin/cu
SUNWcacaort     4511   root       sys        PASS   5bce4227db29f95813a6c7c13cc7d46d  /usr/lib/cacao/lib/tools/cacaocsc
SUNWcdrw        4755   root       bin        PASS   7ab3bed64d212595784a85f65b062d51  /usr/bin/cdrw
SUNWcsu         4511   uucp       bin        PASS   d9ac90c128f8f2750b3a49ae0c340ab4  /usr/bin/tip
SUNWcsu         4555   root       bin        PASS   226f94dd9845c934a98fc7f2aaa19523  /usr/bin/fdformat
SUNWcsu         4555   root       bin        PASS   24cf3f5258e5df4acccfed98a8822af3  /usr/lib/fs/ufs/ufsdump
SUNWcsu         4555   root       bin        PASS   316e3db185c014eae1d7881293a72c41  /usr/lib/utmp_update
SUNWcsu         4555   root       bin        PASS   3bfd7b1fc9811058b24bcbd42f826dc2  /usr/bin/amd64/uptime
SUNWcsu         4555   root       bin        PASS   61c7000154baedd954a9e9dd461e390e  /usr/lib/fs/ufs/quota
SUNWcsu         4555   root       bin        PASS   6269d65e9c176610ca42d498970eeff8  /usr/bin/login
SUNWcsu         4555   root       bin        PASS   6493ff50d04d5cdb4264407f0f2e8c78  /usr/sbin/i86/whodo
SUNWcsu         4555   root       bin        PASS   78fe5243a4dc6a5f4dca4e3e23c6a673  /usr/bin/i86/uptime
SUNWcsu         4555   root       bin        PASS   7b5f21df1819f2b69237579b8a1a0fe6  /usr/sbin/allocate
SUNWcsu         4555   root       bin        PASS   8c97df084b4e5f98e282857926fd86cb  /usr/bin/pfexec
SUNWcsu         4555   root       bin        PASS   bf1cb47e81689184214c6a83f63cdfb1  /usr/bin/crontab
SUNWcsu         4555   root       bin        PASS   c96b766b4ccbac6431b1e815bb65bdde  /usr/lib/fs/ufs/ufsrestore
SUNWcsu         4555   root       bin        PASS   ca0d8f737092afaed8fb083668d80be1  /usr/sbin/traceroute
SUNWcsu         4555   root       bin        PASS   f535cdc0d54439c14d8c92e915df83ea  /usr/sbin/amd64/whodo
SUNWcsu         4555   root       sys        PASS   14bb586161ad6de0d6e8b891a797f385  /usr/bin/su
SUNWcsu         4555   root       sys        PASS   e213aa06105763694156369709f7c0dd  /usr/bin/amd64/newtask
SUNWcsu         4555   root       sys        PASS   f88d0e395c4e5a8403e2273af8d73ea6  /usr/bin/i86/newtask
SUNWcsu         4755   root       sys        PASS   526d58c2ecc92e8678700a8514f697c5  /usr/bin/at
SUNWcsu         4755   root       sys        PASS   8c028119f2a38570f3bac37b4a0f83db  /usr/bin/atq
SUNWcsu         4755   root       sys        PASS   b3013b0aacd83a60208b015d47568040  /usr/sbin/sacadm
SUNWcsu         4755   root       sys        PASS   c84a3ab1da0e4db2fdfb45ea20bdb51e  /usr/bin/newgrp
SUNWcsu         4755   root       sys        PASS   eaaf142b658cafa113a8ec0c41e0ecdb  /usr/bin/atrm
SUNWcsu         6555   root       sys        PASS   5c2f4716b3713a6b3258dc3ef9b3b5c7  /usr/bin/passwd
SUNWdtbas       6555   root       sys        PASS   b7203985ff6f6d5d2d356597a4864d11  /usr/dt/bin/dtaction
SUNWdtdmn       6555   root       daemon     PASS   fc82558b87e32747c81f398a9656e90d  /usr/dt/bin/sdtcm_convert
SUNWdtdst       4555   root       bin        PASS   62343f01fb78de1f18cea2e3dc10bb0c  /usr/dt/bin/dtprintinfo
SUNWdtdst       4555   root       bin        PASS   624a41d131fb86054da0f860c898e97e  /usr/dt/bin/dtfile
SUNWdtdte       4555   root       bin        PASS   86794ad490355171a79d6941f0babde3  /usr/dt/bin/dtappgather
SUNWdtwm        4555   root       bin        PASS   3dd7de38e474409e4e677bacc10130b9  /usr/dt/bin/dtsession
SUNWgnome-sys-suspend 4711   root       bin        UNSIGN 290ca164439161635c0d23d525bcead8  /usr/lib/gnome-suspend
SUNWmcos        4555   root       sys        PASS   381166949a022ebf659ef0cab6e275ff  /usr/lib/webconsole/adminverifier
SUNWmcos        4555   root       sys        PASS   fe73cd9209baf01586c2bc44b003434e  /usr/lib/webconsole/pamverifier
SUNWnisu        4555   root       sys        PASS   f6f934c50750f22791b1a4a23db437cd  /usr/bin/chkey
SUNWpcu         4511   root       lp         PASS   6b71b3fb8bd8edeb77e90bcb40896842  /usr/bin/lpset
SUNWpmowu       4555   root       bin        PASS   ecabbf94c13052cfe793985f388a3357  /usr/openwin/bin/sys-suspend
SUNWpmu         4555   root       bin        PASS   5f13d302a6ae4d5e0d3d03e28fa8f845  /usr/sbin/pmconfig
SUNWpppdu       4555   root       bin        PASS   f762762ffe2349a59156b2621d540db6  /usr/bin/pppd
SUNWpprou       4555   root       bin        PASS   227be03e256c6dcc8c07c45275837195  /usr/sbin/smpatch
SUNWpsm-lpd     4511   root       bin        PASS   69b0a7e7ef6952a3bf0b9094a718b85b  /usr/lib/print/lpd-port
SUNWpsu         4511   root       bin        PASS   e80d4264a38f803dc6ca696d22c0e97e  /usr/lib/lp/bin/netpr
SUNWrcmdc       4555   root       bin        PASS   49fab30241d57a8ab085804312238a94  /usr/bin/rcp
SUNWrcmdc       4555   root       bin        PASS   54391ee93e29e392d094260b3d4b3d68  /usr/bin/rsh
SUNWrcmdc       4555   root       bin        PASS   569ac7fbd0df6eea1430a601b7ecca39  /usr/bin/rlogin
SUNWrcmdc       4555   root       bin        PASS   5f206a9c57570976301642b8a929d94d  /usr/bin/rdist
SUNWrmvolmgr    4555   root       bin        PASS   e8f97baf47fe6400567e0518c259e157  /usr/bin/rmformat
SUNWsndmu       4555   root       bin        PASS   6df3ae57fb3cc0f83bea9f806ebcb84f  /usr/bin/mailq
SUNWsshcu       4555   root       bin        PASS   6a5efb5008794fa74074de7f06e1456a  /usr/lib/ssh/ssh-keysign
SUNWwlanr       4755   root       bin        PASS   b907467dcbc24e79f191fc31f90fae6d  /sbin/wificonfig
SUNWxcu4        4555   root       bin        PASS   97cc4f6659c3f8b85910d28c07c0fa9c  /usr/xpg4/bin/crontab
SUNWxcu4        4755   root       sys        PASS   f4ae837685c632d8df16891caa718053  /usr/xpg4/bin/at
SUNWxcu6        4555   root       bin        PASS   418a5488f784886fb545afc70530e59f  /usr/xpg6/bin/crontab
SUNWxorg-server 4555   root       bin        PASS   5641dd1147ea1a088dba31235d898aa3  /usr/X11/bin/i386/Xorg
SUNWxorg-server 4555   root       bin        PASS   83ece035a60d7f98ed2ab1b15dbd3c76  /usr/X11/bin/amd64/Xorg
SUNWxsun-server 4755   root       bin        PASS   1938f2c3b4548ad0113ce52ef2d3d328  /usr/openwin/bin/Xsun
SUNWxwplt       4755   root       bin        PASS   515b26b22fa5d787808a993512202600  /usr/openwin/bin/xlock
SUNWxwsvr       4555   root       bin        PASS   f2187476d6491e7b439b997259a10062  /usr/X11/bin/xscreensaver


Set-GID Programs

SUNWcsu         2511   root       mail       PASS   0a732e9746d3033f82bd1a19c7521dfb  /usr/bin/mailx
SUNWcsu         2511   root       mail       PASS   38aa1ab24793bcbd9dbff6b22447bf2a  /usr/bin/mail
SUNWcsu         2555   root       bin        PASS   b36e0818f80a0c2e2f0710d23e184d5d  /usr/sbin/eeprom
SUNWcsu         2555   root       sys        PASS   128eeaab017cbb492f0f0bbfcfdc8ff1  /usr/sbin/amd64/prtconf
SUNWcsu         2555   root       sys        PASS   1e60d93817985dedb7720e1e5ab6892c  /usr/sbin/i86/prtconf
SUNWcsu         2555   root       sys        PASS   3099609858ed2234ffaaa597ec5d3bba  /usr/sbin/amd64/sysdef
SUNWcsu         2555   root       sys        PASS   51f912b98d75019889c8921f5b42e826  /usr/sbin/amd64/swap
SUNWcsu         2555   root       sys        PASS   749a05fa3cbe0f27a220678a9defe895  /usr/sbin/i86/sysdef
SUNWcsu         2555   root       sys        PASS   c3ec5940f697917257fca3a16ec1a07a  /usr/sbin/i86/swap
SUNWcsu         2555   root       tty        PASS   091ee44402b7870a55e8f3d47adb7ce2  /usr/sbin/wall
SUNWcsu         2555   root       tty        PASS   26116f7ed5064c4e29720b629d824bb9  /usr/bin/write
SUNWcsu         2755   root       sys        PASS   7b44b3ead9ecda4c465a826c2ab56ed9  /usr/sbin/prtdiag
SUNWcsu         6555   root       sys        PASS   5c2f4716b3713a6b3258dc3ef9b3b5c7  /usr/bin/passwd
SUNWdtbas       6555   root       sys        PASS   b7203985ff6f6d5d2d356597a4864d11  /usr/dt/bin/dtaction
SUNWdtdmn       6555   root       daemon     PASS   fc82558b87e32747c81f398a9656e90d  /usr/dt/bin/sdtcm_convert
SUNWdtdst       2555   root       mail       PASS   36dd0001f2ed41be07b027d1c02d115d  /usr/dt/bin/dtmailpr
SUNWdtdst       2555   root       mail       PASS   fdae40512f82352ba3e74f1b463f97b1  /usr/dt/bin/dtmail
SUNWgnome-games 2555   root       bin        PASS   103f02a4a24446506c7f8ace5026cbe3  /usr/bin/gnobots2
SUNWgnome-games 2555   root       bin        PASS   3db3e19d6299bfa875501179d99846ec  /usr/bin/mahjongg
SUNWgnome-games 2555   root       bin        PASS   411180c45b893cac7c0dc673849c5097  /usr/bin/gnotravex
SUNWgnome-games 2555   root       bin        PASS   60acedf6d46a25884726273d56b7bc0f  /usr/bin/glines
SUNWgnome-games 2555   root       bin        PASS   6f80e05e7b954b46516ca69cd7fc1377  /usr/bin/gnibbles
SUNWgnome-games 2555   root       bin        PASS   7db26899831c27556158d650fc8bbde8  /usr/bin/gtali
SUNWgnome-games 2555   root       bin        PASS   a9694142b04f9cd030b87a2f5392d4af  /usr/bin/gnotski
SUNWgnome-games 2555   root       bin        PASS   b31d94aadd219580d7fc0e8480c35279  /usr/bin/same-gnome
SUNWgnome-games 2555   root       bin        PASS   ca97825cae9ab8fa3a6ee5aff97768e3  /usr/bin/gnomine
SUNWsndmu       2555   root       smmsp      PASS   6350af850a401cb3c609d9e0067958ac  /usr/lib/sendmail
SUNWxprint-server 2755   root       root       PASS   36d71e7b95bf992c9101a0c9f44779fd  /usr/openwin/bin/Xprt
SUNWxwplt       2755   root       root       PASS   59a296e934338ef9fa2d33347d8ed750  /usr/openwin/bin/lbxproxy


World Writable Files

SUNWbnur        1777   uucp       uucp       NOTELF [Target_Is_Directory]             /var/spool/uucppublic
SUNWcsr         0666   root       bin        NOTELF d41d8cd98f00b204e9800998ecf8427e  /var/adm/spellhist
SUNWcsr         1777   root       bin        NOTELF [Target_Is_Directory]             /var/preserve
SUNWcsr         1777   root       mail       NOTELF [Target_Is_Directory]             /var/mail
SUNWcsr         1777   root       sys        NOTELF [Target_Is_Directory]             /var/tmp
SUNWdtscm       0666   root       root       NOTELF eb6d8ae6f20283755b339c0dc273988b  /var/dt/dtpower/_current_scheme
SUNWdtscm       1777   root       root       NOTELF [Target_Is_Directory]             /var/dt/dtpower/schemes
SUNWiqr         1777   root       sys        NOTELF [Target_Is_Directory]             /var/imq/instances
SUNWkrbr        1777   root       sys        NOTELF [Target_Is_Directory]             /var/krb5/rcache
SUNWmconr       0777   root       sys        NOTELF [Target_Is_Directory]             /var/webconsole/tmp
SUNWpkgcmdsr    1777   root       bin        NOTELF [Target_Is_Directory]             /var/spool/pkg
SUNWscpr        1777   root       sys        NOTELF [Target_Is_Directory]             /tmp
SUNWsmbar       1777   root       bin        NOTELF [Target_Is_Directory]             /var/spool/samba


Non-Sticky World Writable Directories

SUNWmconr       0777   root       sys        NOTELF [Target_Is_Directory]             /var/webconsole/tmp

So whether you are interesting in finding set-uid or set-gid programs, verifying their integrity (directly via elfsign(1) or using the Solaris Fingerprint Database) or perhaps something else entirely, the Solaris Interesting File Discovery tool could be another useful weapon in your security auditing/forensics arsenal.

For those interested, this output is from a Nevada build 68 system running in Parallels Desktop for Mac OS X otherwise known as my desktop!

At any rate, check out the tool and drop me a note with your feedback! I would love to hear from you!

Take care,

Glenn

Technorati Tag:

Wednesday Feb 28, 2007

Tracking Infected Telnet Worm Machines

Today, there has been a lot of discussion about the new telnet worm which exploits the recently announced telnet vulnerability in Solaris 10 and Nevada.

Aside from the usual recommendation of you should not be using telnet. You should be using SSH, I would like to cast a vote for the use of IP Filter. IP Filter is quick and easy to configure and can help give you visibility into attacks such as this. Beyond its initial use as an enforcement point (blocking access to services such as telnet), IP Filter is also a great tool to allow you to see what other systems are attempting to do to yours.

An IP Filter entry for the telnet worm may look something like:

Feb 27 15:26:38 blackhole ipmon[100]: [ID 702911 local0.warning] 15:26:38.269526 ip.tun0 @0:11 b 192.168.1.112,55039 -> 192.168.19.6,23 PR tcp len 20 52 -S I

With this format, you could quickly whip up a script to tell you who is knocking on your system's telnet door (even if telnet happens to be disabled - which is the case on my system). See:

blackhole$ getent hosts `grep  ipmon  /var/adm/debug | grep " b " |\\
   grep ",23 PR" | awk '{ print $13 }' | awk -F, '{ print $1 }' | sort -u`
10.1.42.252     europa
10.1.88.164     io
10.1.90.171     castor
10.3.29.39      pollux
192.168.174.48  orion
192.168.43.112  mercury
With just a little scripting, you can easily find out systems (particularly in an enterprise) that need some special love and attention.

Technorati Tag:

Tuesday Jan 09, 2007

Trusted Extensions in Parallels on Mac OS X

What I did over my winter vacation... Check out the pics (Flickr Photo Set)! Gotta love it when things just work! Thanks to Glenn Faden and Daniel Zhu for their postings and ideas that helped show me the way.

Take care,

Glenn Technorati Tag:

Saturday Nov 04, 2006

OpenSolaris/Solaris Security Presentations Page

I just wanted to take a quick moment to announce the creation of a new Presentations page in the OpenSolaris Security Community. This page has grouped together a bunch of the known Solaris 10 and OpenSolaris presentations all into one easy to find place.

To help kick this off, I have also uploaded a few new presentations including:

  • Practical Solaris 10 Security. This presentation was originally given at the NSA Red Team/Blue Team Symposium and focuses on security controls from the viewpoint of someone attacking a Solaris 10 system. The goal of this presentation is to highlight the various protections that exist as well as highlight how they can be used together (in the spirit of defense in depth) to better protect systems, services and data from attackers.
  • Enhancing Security Awareness and Control with DTrace. This presentation was given at the Sun Conference Engineering Conference and looks at how DTrace can potentially be used to provide greater (and more focused) insight into security-related events happening on a system. This presentation was given with a hands-on demonstration. The code for that demonstration will be made available shortly.
  • Solaris 10 Security Technical Deep Dive. This is an updated version of a presentation that I have shared earlier. It has been tweaked and updated to account for functionality in Solaris 10 11/06 (Update 3).

If you have any feedback on these or any of the other presentations or if you are aware of Solaris 10 or OpenSolaris presentations that exist and can be referenced on the OpenSolaris Security Presentations page, please drop us a note.

Take care!

Glenn

Technorati Tag:

Tuesday Sep 26, 2006

Treo 700p on Nevada

Will wonders never cease? Today, I decided to plug my Treo 700p smart phone into my newly upgraded Solaris laptop. Honestly, I was not sure what would happen as this was the first time that I had tried to connect up a Palm device.

My goal for doing this was simple. I wanted to synchronize my calendar to my phone so that I would have a list of my appointments while I was on the road. I had wanted to use something more direct like SyncML, but that option was not available to me. Oh, well... I have been using Evolution lately to manage my appointments. What is interesting about my configuration is that my calendar is hosted on Sun's EdgeCal service which allows me to easily access and share my calendar from the Internet or within Sun. EdgeCal is basically a Sun Java System Calendar Server environment and I use the JESCS Evolution Connector to access EdgeCal. By the way, this all worked out of the box too!

So, back to today's experiment... Since Evolution already has an ability to synchronize with devices such as Palm Pilots, I decided to give that a try. The process was completely painless. I simply connected up the 700p via a USB port (actually on a USB hub since I am also using a USB keyboard and mouse), provided some basic settings information to Evolution (Pilot Synchronization Dialog) and hit the HotSync button. Evolution was able to not only find my device but also push the calendar information from EdgeCal to my phone in a matter of seconds. Way cool.

What is really nice is that I can also use the pilot-xfer command to also back up your device (to a ZFS partition in my case). You really have to love it when things just work.

Take care,

Glenn

Technorati Tag:

About

gbrunett

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today