Glenn Brunette's Security Weblog

HEADSUP: Solaris 10 Security Best Practices

Thursday Jan 31, 2008

Just a quick heads-up note to say that the official Sun location for the Solaris 10 security recommendations documents has changed. While you can still get to the content from the OpenSolaris Security Community Library page, the new location is on sun.com.

The recommendations documents have been bundled into an archive so that they can be more easily downloaded in a single step. The individual documents are still available and can be downloaded at:

World's Youngest Sun Ray on Solaris Nevada User

Tuesday Jan 08, 2008

Well, I can hardly believe that three years has passed since the birth of my second son. In keeping with past tradition, today he received his first Sun Ray. Just as his brother before him, he received a Sun Ray 150. Having used his brother's Sun Ray for quite some time, he took to it with ease and had fun playing on some of the typical kids sites. I am sure he will pick things up in no time with his big brother at his side to help him along.

IMG_4369 IMG_4369_2

This bet on early access to technology has certainly paid off (not that I had any doubt!). My eldest is very at home with technology and the Internet whether on a Sun Ray, a Ubuntu desktop or even his Wii. He recently even asked if he could watch me next time I "fix" (read: upgrade) the computers so that he could learn how to do it. With Indiana, he may very well be able to do the upgrade next time! Even in school where they are forced to use Microsoft products, he adapts very well switching from MS Paint to gPaint and IE to Firefox, and so on. I am sure his little brother will follow in his technological footsteps.

A few things have changed over the years since we started down this winding road... The original Ultra 10 was upgraded some time ago to an Ultra 20. Solaris 10 gave way to Solaris Nevada (and everything that comes with it), the Sun Ray Server Software was also brought up to date, and more memory was added. Time passes and all things must change. In this case, certainly for the better!

With each new Solaris and SRSS upgrade, the experience becomes easier to install, configure and use. My hats off to both engineering teams who do a remarkable job. I can't wait until we get Indiana and Sun Ray linked up! Special thanks this round to Kent Peacock and P.S.M. Swamiji who helped me work out one last kink in getting rid of some very, very outdated Sun Ray firmware on my last remaining DTUs! Now everything from the DTU firmware, to the Sun Ray software, to the operating system, etc. are all running the very latest and greatest - at least until Nevada build 81 comes out!

Happy birthday, little one!

Like this post? del.icio.us | furl | slashdot | technorati | digg

Top 5 Solaris 10 Security Features You Should Be Using

Monday Jan 07, 2008

Inspired by Solaris 10 winning a spot on the InfoWorld 2008 Technology of the Year Award list, I decided to write up a list of my own. I hope you forgive this little bit of cheerleading, but I just could not help myself...

The Top 5 Solaris 10 Security Features You Should Be Using!

This list is intended to highlight five security controls found in the Solaris 10 OS that will offer the most direct and immediate value to you and your organization. I stopped the list at five to simply provide a representative list, but you can see from this deep dive presentation that Solaris has a lot more to offer. At any rate, let's get on with the list... (drum roll please)...

5. Auditing.

Yes, Solaris has had its auditing facility in place since Solaris 2.3, but I can't even begin to count how often I talk with people who do not know that it exists. Solaris Auditing is a great facility to figure out what is happening on your systems. As a kernel-based facility, it can see and record everything that is happening - which is absolutely critical for organizations concerned with compliance. Martin has published a nice audit configuration to address the security requirements for the payment card industry. We also have a whitepaper that discusses how Solaris as a whole stacks up in this area, but I digress... Moving on.

4. Privileges.

You are likely using privileges without even knowing it, and that is a good thing. Solaris has implemented the principle of least privilege across many of the default set-uid binaries and system services. By default, many services are granted only those privileges they need (or simply drop those that they do not need). That said, why stop there? This Sun BluePrint describes how to integrate privileges into third-party or even your own applications. Further, for those doing software development, this paper talks about how to integrate privileges directly into your code to bracket your use of privileges - further limiting when your code will run with privileges. Don't know what privileges you need? Check out our privilege debugger - it will show you the way. By running with only those privileges that you need, your window of exposure is significantly reduced - and we can all agree that is a good thing.

3. Role-based Access Control.

Need to limit access to administrative functions? Do you occasionally need to perform privileged operations? Role-based Access Control or RBAC is the answer. Originally integrated in Solaris 8, RBAC has become increasingly more integrated with the rest of the operating system. For example, if you want to allow your operators to restart but not change system services, RBAC can help. Bart has developed a very nice tour of RBAC for those new to the technology. For those wanting something a little more advanced, you can use RBAC to implement a two-person (or four-eyes) access control scenario. Regardless, of whether you just want to want to just delegate root access or you want to implement a sophisticated access control policy, RBAC can scale to meet your needs.

2. Zones.

You knew I would be getting to zones, right? Zones are IMHO one of the most significant security features in the Solaris 10 OS. Kernel and most user-land forms of root kits are essentially rendered non-effective when running your applications in a sparse-root non-global zone. Zones operate with fewer privileges than their global zone counterpart - making privilege-oriented attacks far more difficult to achieve. More than that, the core OS binaries, libraries and kernel modules are all effectively immutable in the default configuration since they are provided using read-only loopback mounts from the global zone. What does this mean? Simply put, you can't change them. This is a huge win for security, for change control, for IT governance - you name it. You can give access to applications to do their work in a safe environment without risking changes to the underlying OS. That said, if you need to make changes, Solaris is flexible enough to accommodate. You can add devices, file systems, network interfaces, even privileges to zones. You can enforce various resource controls on zones to prevent them from using an unfair share of Solaris resources. What's more - you can personalize your zone with its own hardening configuration, naming and authentication services, audit policy, and much more. You can even do some very interesting things with cooperating zones. Zones offer such compelling security capabilities that they (along with auditing, privileges and RBAC) serve as a cornerstone of Solaris Trusted Extensions, Sun's multi-level operating system that implements mandatory access control.

1. Network Secure by Default.

Last, but certainly not least on this list is Secure by Default or SBD. SBD was introduced in Solaris 10 11/06 as a means of significantly reducing the network-visible attack surface of the Solaris OS - particularly for out of box configurations. Huh? It means that when SBD is selected at installation time, the only Solaris OS service that will be exposed on the network is Secure Shell (rather than a traditionally long list of services that may or may not be used in your deployed environment). SBD can be selected at install time (for initial installs) or post-installation time (for upgrades and when you just want to enable it later). It will either turn off services that were deemed non-critical or set required services to a local-only state where they will respond only to requests coming from the local machine itself. This allows you to start from a more secure default configuration and enable only those services that you actually need. SBD can be configured in the global zone or in any number of non-global zones (since they can have their own configurations). For those wanting a bit more in terms of customization (for which services they want to disable, enable, set local-only, etc.), you may want to consider using the Solaris Security Toolkit where you can set policies against which the system configuration can be assessed or set. Regardless of which tool you choose, you can now more easily lock down your Solaris 10 deployments.

I hope you enjoyed this look at the Top 5 Solaris 10 Security Features You Should Be Using. If you want to learn more about what capabilities Solaris 10 has to offer, you have a wealth of options to help you get up to speed:

Until next time...

Glenn

Technorati Tag:

[2] Comments
Like this post? del.icio.us | furl | slashdot | technorati | digg

UPDATED: Solaris - Now With More Fuzz

Friday Jan 04, 2008

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:

[5] Comments
Like this post? del.icio.us | furl | slashdot | technorati | digg

Redshift, Cell Phones and Sun

Friday Jan 04, 2008

On Monday, December 24th, 2007, Jonathan said:

Christmas Day is a day of massively high load for Sun's customers across the world. This year will undoubtedly set a pile of new records. Millions upon millions of network enabled gifts will be given in December, and a huge chunk will be unwrapped and turned on tomorrow. Digital still and video cameras will start pumping content to photo/video sharing services. Mobile phones will need to be provisioned, and will start downloading and sharing content (on a global basis, the network load from New Year's Eve MMS messages goes beyond staggering). Set top boxes, networked picture frames, video game consoles, navigation devices, stuffed animals, sports equipment and automobiles - will all come on-line tomorrow. On the same day. And everyone will (and should) expect flawless service.

and he hit the nail right on the head. Today (thanks to the Associated Press), comes this story: Congestion causes text message slowdown which reads (in part):

Analysts said last month that Americans may have spent more in 2007 for the first time on their cell phones than on land lines and pay phones. And people are using their cell phones in growing ways — for text messages, video messages, e-mail and Web access.

So, we have more people using more phones for more services... I guess you could say that there were more than a few who were underserved on New Year's Eve.

In fact, so many people tried to send text messages on New Year's Eve that networks got jam-packed and many of the missives arrived hours later — or not at all.

Every day more and more devices are being connected to the network. The more content being shared combined with increasing levels of participation and new capabilities only serves to increase its intrinsic value. The greater its value the more people will want to participate. Every day opens up new opportunity for everyone especially Sun - whose singluar vision "the network is the computer" is even more true today then when it was coined. As the network is flooded with all of these new consumers and devices, will your service be able to keep up? If you have any doubts, give us a ring, I am sure we can help. After all, we have helped many people already and are helping more every day.

Happy new year everyone!

[2] Comments
Like this post? del.icio.us | furl | slashdot | technorati | digg

NEW: Hack-Fu - Deconstructing the Security Capabilities of the Solaris 10 OS

Tuesday Nov 13, 2007

For the Sun CEC 2007 conference this year, I revamped my originalPractical Solaris 10 Security presentation that I had originally mentioned here. The new version of the presentation is titled Hack-Fu - Deconstructing the Security Capabilities of the Solaris 10 OS.

While the title is a little more "catchy", the real change is that the presentation was enhanced to provide a more complete practical demonstration of Solaris 10 security capabilities. The presentation is structured from the viewpoint of a potential attacker examining the system from the network. As each new capability is discussed, barriers are lifted -- one by one -- until the attacker is given root access inside a Solaris 10 non-global zone.

While I have not had a chance to record the talk putting audio to the slides, you can still follow along as many of the examples in the presentation are based upon Sun BluePrints and HOWTOs that have already been published such as:

and a few others. I am always tuning and tweaking these presentations to address new features, improve their clarity, and make the examples more realistic. So, be sure to give it a look and send along your feedback. Also, don't forget to check out the OpenSolaris Security Community Presentations Library for other presentations featuring Solaris 10 and OpenSolaris content!

Take care,

Glenn

Technorati Tag:

Like this post? del.icio.us | furl | slashdot | technorati | digg

NEW: Solaris Package Companion v0.7

Friday Nov 02, 2007

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:

Like this post? del.icio.us | furl | slashdot | technorati | digg

NEW: Solaris 10 Set-ID and World Writable Overview

Friday Nov 02, 2007

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:

Like this post? del.icio.us | furl | slashdot | technorati | digg

NEW: Solaris 10 Security Best Practices

Friday Nov 02, 2007

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:

[1] Comments
Like this post? del.icio.us | furl | slashdot | technorati | digg

Sun SPARC Enterprise T5x20s: A Security Geeks Point of View

Tuesday Oct 09, 2007

What an exciting day! Today, Sun has officially launches the Sun SPARC Enterprise T5120 and T5220 rack-mount systems along with the Sun Blade T6320 blade server, the first to be designed for the UltraSPARC T2 processor. From the point of view of a security geek, there is a lot to be happy about. The UltraSPARC T2 has support for eight (8) cryptographic processing units, each of which supports ten (10) different cryptographic algorithms and a hardware-based random number generator. Lawrence has done a fantastic job of talking about these capabilities and performance if you are interested. It is simply mind blowing.

So, what else is new? Well, we now have actual servers that can leverage the computing power of these chips. This means that companies can now begin to rethink about how they have deployed cryptography in their environments. In particular, it is now much more practical to deploy cryptographic services more widely across an enterprise environment due to the performance gains achieved by offloading the work to the cryptographic processing units. For example, why not ensure that all of your internal web, directory and mail services are fitted for encryption? (Hint: you should be doing this already, but now you can do it while not sacrificing the performance of your CPUs!) Net-net: strong security + excellent performance + eco-friendly is a win-win for everyone.

In addition to enabling the wider use of cryptographic services, I would also encourage any organization to consider how the performance and power benefits of these systems can be applied to their existing environments and workloads. In particular, when used in concert with Sun's Logical Domains (LDoms) technology, organizations can get the benefits of performance, virtualization and security together in one system. Did I mention that today we are also announcing version 1.0.1 of our LDoms technology? Honglin has all the details. Of particular interest to us security geeks is the support for minimized and hardened logical domains! Combine that with the security isolation capabilities of the LDoms hypervisor, a boat-load of crypto performance, and a rock-solid, security, and scalable operating system - you just can't go wrong.

Talk about "zero cost security"! Taken as a whole, you get all of the performance (did I mention the 64 threads?), power and virtualization benefits with security just baked into the design! What's not to like? At least from where this security geek is standing, the view is simply unbeatable. See it all for yourself!

Glenn

Technorati Tag:

Like this post? del.icio.us | furl | slashdot | technorati | digg

Brief Vacation in Niagara Falls

Monday Aug 20, 2007


IMG_1246.JPG
Originally uploaded by gbrunett

It was time for a little mini-vacation. For a few days last week, my family and I traveled to Niagara Falls, Ontario, Canada. We had an excellent trip and with views such as these, you can easily see why! What a beautiful place to take in a wonder of nature.

Not only that, but it was a great excuse to try out my new camera. *grin* I have a few other pictures that I will upload soon that were taken closer to home.

Gotta get back to work!

Take care,

Glenn

Technorati Tag:

Like this post? del.icio.us | furl | slashdot | technorati | digg

Solaris Fingerprint Companion v0.5

Monday Aug 13, 2007

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:

[1] Comments
Like this post? del.icio.us | furl | slashdot | technorati | digg

Solaris Non-Executable Stack Concluded

Wednesday Aug 01, 2007

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:

[4] Comments
Like this post? del.icio.us | furl | slashdot | technorati | digg

Interesting File Discovery Tool version 0.5

Monday Jul 30, 2007

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:

Like this post? del.icio.us | furl | slashdot | technorati | digg

Solaris Non-Executable Stack Continued

Wednesday Jul 25, 2007

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:

[2] Comments
Like this post? del.icio.us | furl | slashdot | technorati | digg