/\ /^/_ _ __ __ _|^|_ __ ___ / \/ / _` '_ \/ _` | | '_ ` _ \ / /\ / (_| |_) (_| | | | | | | | /_/ \/ \__, .__/\__,_|_|_| |_| |_| |_| Issue 4 (Apr 5, 2000) __________________________________________________________________________ The gh0st.net project: http://www.gh0st.net/index.html FireSt0rm homepage: http://www.firest0rm.org/index.html Napalm homepage: http://napalm.firest0rm.org/index.html URL of the day: http://mowse.ne.mediaone.net/index.html All content copyright ©2000 by the individual authors, All Rights Reserved __________________________________________________________________________ - Editor's Comments - URLs - Just Intonation - Securing Solaris 2.x - Music Review - Future Issues - Credits *********************************************************************** *** Editor's Comments : Kynik *********************************************************************** We got some amazing press from the Hacker News Network, and through them, and PacketStorm, we managed to get over a thousand hits within 24 hours of Issue 3's release. We're also up to 70 or so subscribers, and more trickling in every day. I've heard lots of good feedback from all of you readers, and I really appreciate it. What I would ike to see even more, though, is questions from all of you about things you need clarified or can't figure out. As long as it's topical (see Napalm's main page for what is topical) and we know the answer, we'll try to help out. Speaking of topical, as it is mentioned on the main page, we deal with music here, too, so starting with this issue, we're doing some music reviews, as well as a music-related article now and then. Also, if any of you have ideas for topics we should write about, feel free to email us at napalm@firest0rm.org. If you have articles that you've written and would like them included in the 'zine, those can also be sent to napalm@firest0rm.org. Again, thanks for all of the great feedback! *********************************************************************** *** Random good URLs : Kynik, Dogcow *********************************************************************** Packetstorm's archive of Napalm http://packetstorm.securify.com/mag/napalm/ An Australian mirror of software, text files and misc. security info http://www.wiretapped.net/ black.box e-zine http://black.box.sk/ A huge collection of text files on many topics (Napalm's in there!) http://www.textfiles.com/ A Milwaukee metal band http://www.atomicnumber9.com/ *********************************************************************** *** Just Intonation : ajax *********************************************************************** Everything You Never Wanted To Know About Just Intonation or Western Scales Ate My Brain First, some introduction: according to napalm.firest0rm.org:80, "Napalm is an e-zine devoted to computer security, with a healthy dose of music, news, and ethics." Well, maybe we oughtta live up to that, so here's some music theory in your ear. (Or your eye, unless you're text-to-speeching this.) Generally speaking, a scale is a progression of notes that takes you from one octave to the next. (Although it can actually be much larger than just one octave, generally we don't do that.) Notes have pitches, which can be measured in oscillations per second, or hertz. The human ear can perceive from about 20Hz at the low end to around 20,000Hz at the high end. Now, it turns out that the human ear differentiates pitch logarithmically, and that doubling any given pitch raises it an octave. Thus the human ear has a range of a little under ten octaves. Now it also turns out that when the ear hears any two notes in combination, the interval, whether major or minor, is perceived to be in tune when the ratio between the two notes approaches a ratio of two low integers. The degenerate case would be a 1:1 ratio, which would be two notes in unison; a 2:1 ratio, as above, is an octave. Roughly, the intervals for the twelve-tone scale used in western music are: 1:1 unison 21:20 half step / minor second 9:8 whole step / major second 6:5 minor third 5:4 major third 4:3 perfect fourth 7:5 tritone / augmented fourth / diminished fifth 3:2 perfect fifth 8:5 minor sixth 5:3 major sixth 9:5 dominant seventh / flat seventh 17:9 major seventh / natural seventh 2:1 octave The note that a scale centers around is called the tonic. A scale in which the ratio of any note to the tonic is an integer ratio is called a scale of just intonation. These scales have a very natural-sounding quality to them. The problem is, they're murder to implement in any stopped or fretted instrument. The difficulty is subtle, but it means big headaches. It's hard to explain, though, so I'll give an example. For purposes of tuning we need a reference pitch, something all the instruments can agree on. Usually a 440hz sine wave is used as the reference pitch, as an A natural. Now, according to our table above, we can calculate the pitch of any other note by setting up a simple ratio relationship. For example, if I wanted to calculate the pitch of a perfect fifth from an A440, I would write: (X / 440) = (3 / 2) and solve for X. Simple algebra, right? In the above, X comes to 660. Let's calculate two more: (X / 440) = (9 / 8); major second = 495 (X / 440) = (5 / 4); major third = 550 Now, assume that what you know about scale theory is right and that the second of a second (of a tonic) is the same note (and pitch) as the major third of the tonic. If that were true, then in: (X / 495) = (9 / 8) X should equal 550. This is the subtle bit, so make sure you understand it. The above equation takes the second of 440 (495) and finds the note a second up from it (9 / 8). I'll let you all punch that into xcalc and see what happens. Didn't work, did it? You got 556.875, right? This is the problem. Any given scale of just intonation must be tuned to a tonic, which is fine if you only want to play in one key. However, you have to retune the instrument every time you modulate keys. As many classical composers (and pop ballad writers) will tell you, this has a way of limiting your expressive power. So what's a keyboard manufacturer to do? Tha answer is simple: make one note in tune, and space all the other notes equally (logarithmically equally, anyway). This is what happens on most fretted instruments and keyboard instruments. Now, instead of calculating pitch with integer ratios, we just plug an interval into the following equation: P = 440 * 2 ^ (n / 12) where n is the number of half steps sharp you want to go (and hey, guess what, negative numbers work as expected; (n == -3) finds the pitch of the major sixth below A440). This is called a scale of even (or equal) temperament, since the distance to any other note is independent of (and consistent across) key centers. Now, waitasec, doesn't this put everything out of tune? Well, yes it does, but not by very much. Observe: Note Just Pitch E.T. Pitch (approx.) Error (%) A 440 440 0.0 Bb 462 466.16 +0.9 B 495 493.88 -0.2 C 528 523.25 -0.8 C# 550 554.37 +0.7 D 586.6- 587.33 +0.1 D# 616 622.25 +1.0 E 660 659.26 -0.1 F 704 698.46 -0.7 F# 733.3- 739.99 +0.9 G 792 783.99 -1.0 Ab 831.1- 830.61 -0.1 As you can see, we're never more than 1% out of pitch, which most people can't hear. However, you *are* out of tune inherently, so when your instrument then goes further out of tune you sound *really* bad. The advantage, though, is that you get stopped instruments, which makes composition and playing much easier. (Of course, you'll notice I cheated, and listed a just intonation scale that happens to be close to the 12-step equal temperament scale. Sue me. There are also Indian raga scales and other non-standard scales that are "just intonation" scales, but I wanted to present something understandable.) *********************************************************************** *** Securing Solaris 2.x : echo8 *********************************************************************** Files relevant to this article are located at: echo8's Solaris-securing script http://napalm.firest0rm.org/extra/sol.secure Solaris is Sun's proprietary UNIX operating system, based on SVR4. It's currently one of the most, if not the most, popular flavors of commercial unix. While source code is available under various educational arrangements, it is not freely distributed. Solaris has a long and distinguished history of security problems. It's not the worst of the commercial OSes in this regard, but it does not, in my opinion, rival many freely available OSes in terms of "out of the box" security. Nonetheless, as Solaris is very popular in the corporate world, many sysadmins find themselves called upon to deploy it into applications where security is important. What follows is an attempt to summarize what I have read and learned through practical experience with regards to how to make Solaris useable in an environment which is less than fully trusted. I make no pretense of being able to address all of the problems: I can't. I'm also not an expert programmer, and I don't have access to Solaris source. However, it is my belief that if one must use Solaris, the bar can be raised high enough to maintain a tolerable level of security in some applications. Start off with a minimal OS install and Use the Most Current Version -------------------------------------------------------------------- When you install Solaris, choose to do a custom install. After selecting the distribution set to use, pick and choose exactly which packages you want to install. What to install will obviously depend on your application, and you may discover later that you left out something important. You can often add the necessary packages from the CD at a later date without reinstalling if you find this to be the case. The second point is a little more contentious. My opinion is that the best course of action is to use the most current release whenever possible. While it's true that new releases often include new bugs, it's also the case that Sun tends to be more reponsive to holes in the newest versions, and that the newest versions tend to incorporate more fixes for known problems (ie. there is less ground to cover from the beginning). Install the Recommended Patches ------------------------------- I can't stress this enough. While they may take their time about it, Sun does fix holes. It's not at all uncommon for Sun to fix a hole without documenting it (I can think of at least two examples that I'd be happy to share upon request). While installing patch clusters on large numbers of systems in a production enviroment is time consuming, the benefits are obvious. If you need to remain secure, patch frequently, period. The patch clusters seem to be updated very frequently; it's not a bad idea to download a fresh copy whenever you do a new install. While patch clusters are still available for all released versions of Solaris, it's often the case that holes are fixed first in the most current releases. [ They're also nowhere near as bad as some nameless, non-unix-making companies in terms of releasing patches. {ajax} ] Turn off Any Services You Don't Need ------------------------------------ Like many commercial OSes, Solaris comes out of the box with just about every service imagineable enabled. At least the following are enabled, by default: ftp telnet name shell login exec comsat talk uucp finger time echo discard chargen daytime sadmind rquotad rusersd sprayd walld rstatd kcms_server cachefsd kerbd in.lpd xaudio rpc.cmsd dtspc rpc.ttdbserverd keyserv sendmail snmp (various utilities) The vast majority of these do not need to be running in most environments. Many have known security holes, and many more give out information about your system that you really don't need to be giving away. Start by going through /etc/inet/inetd.conf and commenting out everything that you don't need. If you find that you don't need anything there, disable inetd entirely. If you don't need rpcbind running, shut it off too. If you need either one, you should consider installing Wietse Venema's version of rpcbind [1] (which restricts connections by IP address or range, which is better than nothing) and xinetd. [2] Both of these allow more control over who is allowed to connect than the default Sun versions, and the source code for both is freely distributed and actively maintained. Do the same thing for the services started from /etc/r*.d. A lot of systems don't need to have a lot of these running. Look at disabling at least the following: In /etc/rc2.d: S74autofs S80lp S88sendmail In /etc/rc3.d: S76snmpdx S77dmi Read your rc scripts carefully. If you don't need it, don't run it. NFS/NIS ------- If you don't absolutely need to use NFS or NIS, do not enable them. The security implications of NFS/NIS are beyond the scope of this document, but suffice it to say that both present serious issues. If you absolutely need NFS, look into using secure-RPC. NIS+ is preferrable to NIS, but it is still best not to use either service if possible. Thankfully, Solaris 2.x (unlike SunOS 4.x) will work just fine with naming services other than NIS. It's also worth pointing out that Sun has plans to drop NIS+ support in the near future. If you choose to roll it out because of its improved security, you may find yourself on your own as far as "official" support goes before too long. [ Note that NIS and NIS+ share no code and have very different database setups, so if you do end up having to convert, life will not be fun. However, back when Solaris 2.4 was released, Sun dropped server-side support for NIS from the OS and made plans to throw all their weight behind NIS+. Look how far *that* got them. Like echo8 says, if you don't have to, don't. {ajax} ] If you must use NFS, be aware that even if you manage to use AUTH_DES or AUTH_KERB for authentication, NFS traffic still traverses the network in plaintext. [3] If you need to use NFS, be very careful about which hosts you export filesystems to. Export read-only where possible, and consider using fsirand to install random inode numbers on the filesystems you're exporting (to make filehandle guessing harder). [ How would one go about guessing file handles and then using that information to gain unauthorized access? (NFS is pretty foreign to me at the moment) {kynik} ] [ It's like TCP sequence number guessing. NFS uses an amalgam of information in constructing filehandles, including inode numbers. This is used as a token to determine which file is being operated on. Now, most of the time NFS uses UDP, which has no sequence numbers, so if you can get the filehandle you can spoof NFS operations, like corrupting or unlinking files and such. This is why NFS over TCP and Secure RPC are Good Things; now if only they worked... {ajax} ] [ As an addition, file handles can be constructed without the assistance of the mount daemon, which enforces access control in the Secure RPC scheme. In this situation, the client can communicate with nfsd directly and proceed to operate with exported files. This bug is relevant specifically to the Sun Microsystem's "Secure NFS"/ SecureRPC implementation and has been patched. -phatal] Remove as many SUID bits as Possible ------------------------------------ Solaris comes out of the box with about 100 utilities installed setuid to root. While many of them need to be suid root in order to have all of the functionality Sun intended, there's a good chance that any given installation doesn't need all of that functionality. Furthermore, many of these programs have a history of bounds-checking problems that can enable local users to gain root privileges. Without the suid bit set, such buffer overflow attacks don't often yield as interesting a result. Use the find command to locate all of the setuid and setgid programs on your system. Remove the suid bits from the ones you are sure will only be run by root, or where you don't need the functionality that requires the suid bit to be set. It's also a good idea to make a list of all of the programs that you leave suid/sgid, and to store that list someplace other than on your system. It's an even better idea to use a utility such as tripwire [4] to keep tabs on ALL of your binaries, suid/sgid or not. Casper Dik's fix-modes program [5] can be useful for changing permissions to increase security. Sun's aset utility is also useful in this regard. Kernel and IP Stack Defaults ---------------------------- Configuration changes can be made to the Solaris kernel and to the tcp/ip stack to somewhat improve its security. Adding the following lines to /etc/system will make the stack non-executable (providing some protection against buffer overflow attacks): * make the stack non-executable set noexec_user_stack = 1 * this logs attempts set noexec_user_stack_log = 1 [ Note that you can patch the Linux kernel to do the same thing. Solar Designer's patch is at http://www.openwall.com/linux/ {kynik} ] [ Programs which map the stack executable will have problems running in this environment. See notes on the Sparc v8 ABI vs. the v9 ABI for more detail. -phatal] You can deny access to NFS exports by non-privileged clients by adding the following to /etc/system: set nfssrv:nfs_portmon = 1 (for 2.5 and above) or set nfs:nfs_portmon = 1 (for older releases) To keep from being smurfed, configure your IP stack NOT to respond to ICMP echo requests from broadcast addresses, or to forward them: /usr/sbin/ndd -set /dev/ip ip_forward_directed_broadcasts 0 /usr/sbin/ndd -set /dev/ip ip_respond_to_echo_broadcast 0 Configure your IP stack to drop source routed frames: /usr/sbin/ndd -set /dev/ip ip_forward_src_routed 0 You might also want to disallow routing between interfaces (if you have more than one): /usr/sbin/ndd -set /dev/ip ip_strict_dst_multihoming 1 All of the ndd commands can be added to the end of an rc script so that they run at every boot. EEPROM Security --------------- It's nearly impossible to effectively secure a machine which is in a phyically insecure location. That said, taking some basic precautions is worthwhile. Either at the OK> prompt, or using the eeprom command, set the following parameters: security-mode=command security-password= security-#badlogins= The first two will restrict the command set available at the firmware prompt until a password is entered. A user with unrestricted access to the firmware state can, for example, boot from alternate devices, change device aliases or change the uid on running processes. [6] The third parameter defines the number of times the user is allowed to attempt to supply a password to enter the unrestricted mode. [ You Solaris people running on the Intel x86 platform need to set a BIOS password to avoid the headaches described above. Granted, one could pop the case open and clear it with a jumper, but I imagine there's a way to do that on a Sun box as well. Anybody know? {kynik} ] Process Auditing ---------------- Solaris ships with a fairly robust and configurable facility for process auditing. The interface is not particularly intuitive, but the package allows a extensive logging of kernel and user-level events. The Basic Security Module is installed by default if you install the full distribution. If you do a minimal, selective install, make sure you include the following packages: SUNWcsr, SUNWcsu, SUNWhea, SUNWman. While configuration of auditing is beyond the scope of this document, you should probably consider logging at least the following event-types: network, process, administrative, login_logout, application, exec, other, and non_attrib. If you really want a closer look at what's going on, you can also enable the file_creation, file_deletion, file_attr_mod, file_write file_read and file_close classes. More extensive auditing (down to the system call level, for certain calls) is available. Process auditing can impose a serious performance penalty, depending on the extent to which you choose to audit. Make sure that you have the necessary storage space and cpu cycles, especially if the application is performance-intensive. Thought should also be given to how to secure, replicate, and store your audit records to prevent their being corrupted if your system is compromised. Full documentation on process auditing is to be found in the SunSHIELD Basic Security Module Guide, which is part of the System Administration Answerbook (Vol. I). Other Add-Ons ------------- In addition to the third-party products I've already mentioned, the following products are not part of Solaris, but can be very helpful when it comes to increasing the security of a Sun system: * Secure Shell (ssh) - a replacement for the r* utilities for remote logins and file transfers, which provides strong authentication and encryption. At least two viable implementations for unix currently exist. [8][9] * Super User DO (sudo) - a utility which allows an admin to give specified users access to specific commands with root privileges. In conjuction with inventive programming, this can almost always preclude having to provide root passwords to anyone other than a qualified, trusted admin. [10] * TCP Wrappers - Allows an admin to restrict access to inet services by IP, and provides logging of all accepted and denied connections. [11] * IP Filter - A free packet filter, suitable for use for firewalling. [12] * nmap - The premier port scanner. Very useful for auditing systems. [13] * anonftpd - Dan Bernstein's read-only anonymous ftp daemon. Useful if you must allow anonymous ftp downloads. [14] * tcpdump - a packet sniffer. Yes, I know that Solaris comes with snoop. Use tcpdump and like it. [15] * qmail - Bernstein's mail transfer agent. A good way to be rid of sendmail. [16] * argus - a free intrusion-detection tool. [17] [ I hear tripwire is good {blakboot} ] Conclusion ---------- If all of these steps are taken, I believe that it is possible to "raise the bar" sufficiently that most compromises of Solaris servers can be prevented. This is obviously not a recipe for total security. Most of the advice in this paper consists of removing functionality from the OS in order to increase its security. This is not possible in all applications, so the kind of host-based security described here should always be implemented as part of a broader plan, which includes carefully-written policies and operating procedures. Other mechanisms for increasing a site's overall security (eg. firewalls, IDS, vulnerability scanning, careful user education) should not be neglected. [ And DO subscribe to mailing lists. {kynik} ] Appendix -------- The accompanying code is an example of a semi-automated way to implement some of the modifications advocated here. It is just that: an example. It was not meant to be a comprehensive or extensible piece of software. I am aware that products like Dan Farmer's TITAN [7] are available, and they are probably more suitable for intensive use. References ---------- [1] ftp://ftp.win.tue.nl/pub/security/rpcbind_1.1.tar.Z [2] ftp://qiclab.scn.rain.com/pub/security [3] http://www.sunworld.com/common/security-faq.html [4] ftp://coast.cs.purdue.edu//pub/COAST/Tripwire [5] http://www.fwi.uva.nl./pub/comp/solaris/fix-modes.tar.gz [6] http://www.2600.com/phrack/p53-09.html [7] http://www.fish.com/titan [8] ftp.cs.hut.fi/pub/ssh [9] www.openssh.org [10] http://www.courtesan.com/sudo/sudo.html [11] ftp://ftp.porcupine.org/pub/security/ ** [12] http://coombs.anu.edu.au/~avalon/ip-filter.html [13] www.insecure.org [14] ftp://koobera.math.uic.edu/pub/software [15] ftp://ftp.ee.lbl.gov [16] www.qmail.org [17] ftp://ftp.sei.cmu.edu/pub/argus The Solaris 2 FAQ - http://www.wins.uva.nl/pub/solaris/solaris2.html The L0pht - www.l0pht.com Packet Storm Security - packetstorm.securify.com The Bugtraq Archives - www.securityfocus.com Please address comments to echo8@firest0rm.org. Copyright 1/2000, Firest0rm Security/Gh0st.net. A big thanks to everyone who read this for me and sent comments. You know who you are. *********************************************************************** *** Music Review : Kynik *********************************************************************** I plan on doing at least one music review per article, with bands being chosen by different people, and getting reviewed by at least 2 others. Each reviewer will give the song a ranking from 1 to 5 in 4 categories: Originality, Talent, Production (how well the song was put together and/or recorded), and a fourth category ranking how much the reviewer liked the song. Thus, a score of a 20 is perfect. Observe: Since this is the first one, I'm choosing a band I found on garageband.com called "Regrets". We reviewed their song "Hate This" this issue. Their homepage can be found here: http://www.angelfire.com/co2/Regret/index.html Kynik's review -------------- Originality - 3 Talent - 4.5 Production - 3 I Like It - 4.5 I was immediately impressed by the drummer in this track. He's tight, relatively complex, and mixed rather well. The band tends to stick with the tried and true "hardcore" sound, but with a drummer like that, they're liable to get real big real quick. The vocalist is mediocre, and could liven up the song by adding a bit more melody. The guitars sound far too fuzzy for my tastes, and it's hard to distinguish if they're playing one chord or another. The 3 riffs they do play are decent, but similar enough that it seems a touch repetitive. (Then again, what song isn't, to a certain degree) The track could have been mixed better, as the vocals tended to fade to the background. All in all, I would pay for a ticket to see Regrets play live. Druid's review -------------- Originality - 2.5 Talent - 4.5 Production - 3 I Like It - 3.5 "Hate This" by Regrets certainly does its job well. It's a heavy aggressive, ear pleasing (if you like metal, that is) track. However, its real job seems to be that of filling a niche. "Hate This" is good to the point that you *swear* Regrets is a popular band. You *swear* you've heard "Hate This" before. They're not, and you probably haven't, but that's the niche "Hate This" fills. The guitars in "Hate This" are good (where have i heard that riff before?), and the lyrics very angry, and very distorted (maybe a bit much - slightly hard to understand.) the song flows really well, and the background sounds blend in well. Not a bad song - in fact, I like it. Just sad that they don't apply thier obvious talent more, instead of sticking behind the "safe" metal front. Euchlid's review -------------- Originality - 2.5 Talent - 4 Production - 3 I Like It - 3.5 Originality only got a 2.5 out of 5 because I think I've heard it before. Talent was not quite 5 due to singer being a bit crass but points for kickass factor. Drums were a bit hollow sounding and the intro went on a bit too long. All in all, a good rockin' tune, lacking slightly in originality but making up for it in aggression. Vocals sounded a bit raw in a tinny way but the drums kicked ass and the song really hit the spot. Overall rating -------------- Originality - 2.67 Talent - 4.33 Production - 3.00 I Like It - 3.83 Total - 13.83/20.00 (69.15%) *********************************************************************** *** Future Issues *********************************************************************** Contemporary Telenet : Blakboot *********************************************************************** *** Credits *********************************************************************** Editor: Kynik Co-Editor: ajax Article Contributions: echo8 Music Reviews: Druid Euchlid Commentary: Blakboot URL Submissions: Dogcow *********************************************************************** *** Subscription *********************************************************************** To subscribe to this 'zine: Email napalm@firest0rm.org with a subject of SUBSCRIBE To unsubscribe: Email napalm@firest0rm.org with a subject of UNSUBSCRIBE or find us online at: http://napalm.firest0rm.org/ Submissions, questions, comments, and constructive chaos may also be directed to kynik@firest0rm.org or any of the contributors ***********************************************************************