8672941 2002-07-01 10:32 -0700  /26 rader/ <gobbles@hushmail.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-07-01  21:49  av Brevbäraren
Extern mottagare: submissions@packetstormsecurity.com
Extern mottagare: vulnwatch@vulnwatch.org
Extern mottagare: bugtraq@securityfocus.com
Extern mottagare: alan@redhat.com
Extern mottagare: jesus@jesus.com
Extern mottagare: dugsong@monkey.org
Mottagare: Bugtraq (import) <22902>
Ärende: Proof of Concept Code for OpenSSH
------------------------------------------------------------
From: gobbles@hushmail.com
To: submissions@packetstormsecurity.com, vulnwatch@vulnwatch.org,
 bugtraq@securityfocus.com, alan@redhat.com, jesus@jesus.com,
 dugsong@monkey.org
Message-ID: <200207011732.g61HW0w84242@mailserver1.hushmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Remote OpenSSH exploit for 2.9.9-3.3.

Check out our official mirror while we work on the bugtraq.org
hosting situation, http://www.immunitysec.com/GOBBLES/ (thanks bob!),
we have a new comic posted and some other miscellaneous stuff.

If you haven't patched your sshd yet, you're probably running OpenBSD.

- -GOBBLES Security
"For the love of God, we won't shut up."
-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wlwEARECABwFAj0gkUAVHGdvYmJsZXNAaHVzaG1haWwuY29tAAoJEBzRp5chmbAP6S0A
n3e3SbTXYt8NbFeKFGcw5tK5Kjk0AKCiOBoaEu/hQ7ryuaJO3KZIB9ae+w==
=X4Ou
-----END PGP SIGNATURE-----
(8672941) /<gobbles@hushmail.com>/--------(Ombruten)
Bilaga (application/x-gzip) i text 8672942
Bilaga (text/plain) i text 8672943
Kommentar i text 8672951
8672942 2002-07-01 10:32 -0700  /84 rader/ <gobbles@hushmail.com>
Bilagans filnamn: "sshutup-theo.tar.gz"
Importerad: 2002-07-01  21:49  av Brevbäraren
Extern mottagare: submissions@packetstormsecurity.com
Extern mottagare: vulnwatch@vulnwatch.org
Extern mottagare: bugtraq@securityfocus.com
Extern mottagare: alan@redhat.com
Extern mottagare: jesus@jesus.com
Extern mottagare: dugsong@monkey.org
Mottagare: Bugtraq (import) <22903>
Bilaga (text/plain) till text 8672941
Ärende: Bilaga (sshutup-theo.tar.gz) till: Proof of Concept Code for OpenSSH
------------------------------------------------------------
‹„ =ì;kwÛ6²ý*ý
T9‰%[RDêe˛¦vâ$ÞÛ©¥´»·éáR$(!¦H•?ғûÛïÌ )™’“¶ÛýpW‰,ó¼Æñ<MÒe2çáÓoþMÖëû}ö
cÆpЕ¿ýþêO‡±aßèÀ¿¡Ù…ÇfÏì}Ãúÿ.„ŠŸ4N숱ol_8ÂÞÜ/I£+~÷W`ô—~â‚üáºí
Ïû³ç0:A¯·IþÝ®a˜RþÁÐì£ü{fÇø†uþlDÊ>ÿÏåòf­”Mmç*]~z.yzÐê¶{Kƒ4Âa%mÕV«µmLel'ìïiÀ̐æÈ茺}fv:fuoo¯`e’rà3f²ô6F¡ðý÷¬eôM£Çöð·g°ï¿¯²§»ì=ñ¥/x¿×Üe^±™NmÚ~MyœÄl÷i•œá0$́AbÉ^–êe	—=cÃ*«îa§ÚD0“mÔâÌÓàʊÅ'^hLœÐåcYh‹×ڜ9¨ØnœÜù8²ƒ"Õ ùŒ'óÐeùóŒCüCÒÞE'f6›s	=â؞q–„*Kcµ›ÌE̼4p,à×<ŠAOƒ¸Mg4_‡Â­Â0€QÇëF•ýVmU¼%ÎâÕãÄåQÔdµ÷ØcÄÇìçp‰Pã_Ø<Œö³.vàþò!¨5™e-£pØތïƒy}q|üödÌÆ'/Þ_žNþÉZì§7§““7G“1{w1žœž¿f“vüþõäòèöêⒽ::;àå/@_Æã7Ìl´Z·ÝJaÂA&¶ïó`Æ[—€1güvé‡"Ùí‘Á¢$Êó¯ï…ª2]iï쌘…KærÛýl„±‰S÷ùÃÊÈ¡£ÐwñÃ.OŽ^²É›öæâ'àÖ«Ó·'ìôœZ&G—ÇGoß2ê(Á”ÌÃXË'e!;û6œòÃ=*u‚ºCÍöFLĒ-Ã(!/ àN"õàPÄ1P÷`JÙø–ÆXöØýL«?‚ñ	8Œuùµp8«ãJa°ž§±k§É¼±RñãrÏNýd¤ÇmC`Ì亄ϩ§¸£†5Yœ£D½¾v~ÄÛä.š/9fæ†Å°Ü}4ØÎíÍ:¼a>p¡«ßˆdÎZŸ쐩»0M°àU*•
è|ddÜHÔhëèökqèu¬n°%¬mkE9ñJ±ZèQþ0@s&¨Þ.Ó¬”oÀäSå$°§ 
Úø/m4\ç#äÑ4Œù!sE¼ôí;v-±i:›4iÇãm+¢ø9zÄЁyDàD܎ÁÓI¸"¹Ó`	u6€ ‡vÉ]¡:‹`	êàEáºXïŽ&o¬—'?ž¿ƒRko³&¯˜ž˜I‰á…'»zÆúÿ}ú8n ˆ&@ I%x0ÞÖûñÉ¥õââü2˜‚üúÐhCðëûM£K~ý &ـ@’S3IîØþбÁ
Ø,Iî¸À€3”·b`¢f[‰šä0_†gª\â.ÿ¨üKA~½üËÉú±@VŽPL¡Bº˜‚½;ˆwEÎ;+Œî× û,±‚/‡ókç‡TðXDà4£ìàŽÝØQP¢r€^ðU]aLR4:‹Âän{	Ї&Â<pïèn·¤8BºÉ1O{)Ûl@B „ßف(
°&QÐú†èðsÄrN~X99Ò¼£0˜:#°R‹m.ØÂvb‰à’;»cgG/ò±1…½v$¡ú™¤Í­Êûgyör”ß2_Ä	ZØs„ÁÑHM2q»•É—8À¼* ³]"¹xäË!+X´œèaÈÅÏdÎaí:6xó
MJŒv$»0ŠC¦Ø4SÙ½’;6lÏ4;Í!Y¹RºB¶#ƒÉˆÿCp%v‡JOb4m"¥‚ÙŽíJn+›œF¤æd‘·Ê%Îi<
®Ã+ž™Ë:þµ“0ºkàl`´M§Óøè^l…9%æÌ·ÄëÓwšÝ™“ÒvßŠ¤n ¨Ï¢ wÌa·¹Ü&™ûĞ*³g¶FÐýfN.¦\€Å7ã	\Ôm˜}ݽÆ)k†ÙØӑ3â#o&FWþh1
ÂÑrôkœ\ß½x9z5:½¿»M~üG­Ñ`ß>©4 
Ú[á* ‹`¢ú”C:#Xã{ÐX¥CÈáÌ",áW0Ûlg©ÞUtìhvHmSèÕaÞùlgDí«'‘³XÖe÷¦JaÒ,oK܇‘eT8»2æ¸0æžD[g#ŒžØNµƒøŽ‚±£#—û(»
åbBÊ$F}T£Vr뇇EjXüU“}Ò(f©½±Ò‘éŽÆª^¥¢r»vfXŸáª°Þ]^L.,ƒ豨Èýý>.óyÐ4:rW ™¿ÄÅ*WэpyɂUy.ʾR‘é:®vK>°°{]FUo •¦ˆêôµ…AU“RÐ&{¢Ð¦åúk
B¸2段êc¬K€°§!˜ÏhGϱÖ)²Ñ XÂI,œÅ‚Ζ3ç”5«2Çvv™XYaȏWÂ÷ט |©*\T€HßRm–‚Z/õpÕj^Rdš?PµšmÕj¾Vµ2û£^'¯Z™¤
ðWµGÃù)(Àß@žÊܲ=ÿ.y«{Éݒݤö۸Ɏ?3Y&:T•¡2’ ä]‘Ž$@
«"%ÅR}0EÀIGï'oP[¬§ïޜ\V°M^Zݗ'cÀâAî*÷WVÌmçuÖí+YžÛÊyÈA‘õøcÈraœÜÒN,ðo¶ùex×e”`©`‰VËBÄÍ·®’Ö=öGàø³gŒ4úÅÅ[ëìèï—–Áž<aºÖûœžcŸFM2µµŸwÑQ
UØât‰1D̀HSY´Î+ƒnW¹!¤˜±¨ÑÅÁ@ŒöDE쥓"+gƒ˜¢¾ŽúÁ$Ù7 bÙëõ:p‰…Í4õšT =F×5ФÖc·ýØm=nN\È%÷Í{¾Î;“î±së(â&Ž"t
 ÿxr9>½8'ޑWW•H¸ ¥à#ÂaýÂfÞ,rV˜‚é”D%‘Ï$Pºöâ=²Ìòë51b’Ö
ÓFuø„
šSUš•ŠYh@É\Þ•›.	æ˜3…¦¹eř_¸äÌß»æ̇¨
¬9ø{ ôbAZ‰ˆß‚K	dšµ[ʕõN1å÷:í­vÂX*o,Ô훅r}3¯Ò7óâ|>l¥Ÿã¡ê´*É=ݕ¦"y
è»j]àª:ûë$·	b¼ ­C”Àª£NJœ—Ò¢:j‡™U±-]Å^óϤwº÷ÕÔµ
.z­«ŒjɁDrÐk}¹z5fmx!î|X1灲vr…è:T|Æ°2TT|Ð	kÇØÕ1B%€ Ÿ´9S@6	œÓݦÏz?F7i[óYŽU´L㹕êjõex)½@È
¶§')ޛ
ih5²
Jƒy6øCWE¯±2b µÇñè1®ß²š²î+•u<Q‘0ÌBŠŠæ½Ðw
(3,¥"ŒD aû9×ÃdP¤[-äeý‰¥RÌn—RÌn?K13uÜÕ]Y­–Rñ¦µL
YëëҎ¤«°kÆQÎÚ1®*K™–P•1ÓٟF`/ƒp=P“À’«iJz}IɁ®	VBÈl0o<± ´„:YYÕHá¨Åõ*ßMXïíåÊ
ÿëšô憸WiQQ eýtFe_}XÊ$í¼W¼÷6Tz\ó™<9òZóR‡ø쇳zí(g¥®vëŽqê`
¡-½U!ëµõ°?™ƒ/€KBAJ›ZJQ‘=J&ûÆSš½ýî~Óìd¯ vé
åè2pÒEiéué8—ïžikږUH+ô¬¥Ç7aäbÕºÅDÜɤ¼"+ÀÑÕ7Š„%
ëlüšŠËØZ§ç¯.¬Ë“ޟŒ'lnÇlŠöŒ,¢Vö£Àí[­Å­ïV¬¢T™5ü¿dˆ
¼”mSm2æËtE'h“«Tø+)¬p\@åæ¬þ8nÜ´bÁŠð>#—I+ºõZ¶LÁ·à‘æ3-×¥6U°v‹2´%õíbhJÓp¸*UÒª®Ù4{ Uƒ.,õ¾^봘Ñx8Òé×sn£Ù/®úòŽ’÷­ï²]ؒÞ5¹F9ºoC\’émIÿMþWîVÆì¹
[ê7bµbIóó2)*Lö²TZé8V¥¦²aY5hm$y°ŒnôÞu噾JÖOÖì¾V‚¿¡ŠÀl•×t`ޞא! LƒÏŽþ×i_g,Ó)-4×mܬ^¯Û
X¡õ)„íÏތ軃ˆ!\×MÐ9oaÌ?†S¬QøtPbO (Ê®NÇ:Bç
€‘U€[ÑdÁ¡ºoîê26è8.֍ž‹ìcžK·¥Xn~
¦:¹Æ½I!BRàýltÌÞ/yÐè,ÜOX£IQ¡YË>Xj¦#rŽÃC¥5Éu;¹†©ŒûÐA{ՓT>êÈ¡•W/­ÿ9¹¼¨?ĤF@ËødRO^žžSYéü¤ºþy‘7ë9´‹¥ÒFE³
†8Aš!‡JË ÿJ>§;Ü“ä¥Ù!ºVJóº2
¨œŽ×¹ß;‚cêìb=M
B^ÓXLùþV6iù§²”)_@6jEfl§—]Ù3\Š_DV2èÐÕÊ÷`ªºL\ßB®ä\…”Lâ0
ࢪ­ˆ*–“:‹_0FÜy½³}Hqh¶„öö¶sµRÑÑÖWVë`soM<P‘ƚéÒ6Áx@'°ïz]B*gíÜ·ñ€NmŽ6#«fàMc(ó¹\Yð	£‚ߤÑÀ̈́Ëûâý$[ßr5:Ø(Ud&?«±¬4¢N¶øÞ*/±H_ºLÕt÷lÀ*È?hV>¿Ó.?…Ðïë,ÂfX•äw1\7Èj-‚ÜF¬…ØÐØñ³,NWÛÅô4e5(½<p†;TP]Æï.ÎÇ'8’\yRqCQ×µ”&KÑ9wMË¿6iøH̆«äÉib%ÈÊNý™SûpÛ5>Ü:·}øì·FoíZÝãw
_§_÷Ãí~§&ðé‡[+÷Ks­Nƒ¬Ùd €Áþ‡ÛÞpõ»€»«Ø¿ÎàÃm03{
¼éwó8Ð565e¸†__&uñÚÆ>
ˆ£hÜïk?ÜH¿ÄÎžÒÌrRêã¬abb#á9	HRq ’P¼7©2Ðö×:«÷Æ`”X¤¯Ètíþ@vÆ{!’Þw×Ä«ˆÌ29`Œ6‡›¥ƒ<Z‘Μ7~ÙußÐJ§€n.•þþýo°ë€!òiš·÷Œ9ÞA.‡KíЃÎ9F®Gol­'
‹]Ø/ꂼït•xEàÈ §ÑÅÁ]}o¨eŠ×C²ˆiË6üí
¤;éõ‚h¢¦	úÞX]Á¤|÷D¬MÌ0¾˜ž3ÝïË{ü`²ÁA>aFÎFFÝ|Öî4ç›ãÔô¶Ä6Û½½n×RÙ&M¶+¬_íbî
?ÒÈ…Uò졬?ب|ÈÓâ(V!óŠçÄtI¦ÉÎNe@g꤆j–…&uì\–Ì{5@mÈ©† +C*QÃ̶Ìo½ˆó:"©òÏ«@˜»ÞÐF¸p~ pó¼x#§"â« ;·½Žü@nRèÿ”õäNº¶
ø¶c>g‰‡ÍRá»TÉ2=…›Ú¸5LÃWE\î¶%Ÿä‰AG“ Óµpå‘llè„¦>¡çåy$ºp©¯äځäšÙov{+e|›eK’.ízAùXàˆªžf„AÚùº¦JökiÀ³TNPZxÐà”À ®P;5:q-åȯŸ®ÕùfYÀ_{Å¢¡~¨û`âBϸÐs áW²\»@±”tEùjҔWd”¹úˆµd´žøKæ)Ÿ¢úšìÍþô+úy¡ê‹xÄ»9Åt—óé1}£
Ôûn}gÀCÖÙ‰>›óœÕÔe
fª&CUk¹¿Uê06£¢4aŽ5]Gf³•ä6.ù-Ov©(vÅ)Ö«
'-γy€‹s0h¦:$mš Žå”n[ Uvq«LWòé}€Á(œŽmËJ¥>5’A²]×ZÂÄhÐ+®r]ÎËDOiuciA+e5¯â^K¾O.‚zCŸÞ+¼TUýO¿ÉößÏïùßÿìt­“É›Óã?yŽíﲞ9TïÿvzýAπÇÝawðß÷?ÿŠÏíÆ{|ÀW&À¦@@’Ú~K2É\xƯÝnÓÞ±_ÞVõŧsûš£1ǎšì.LÙÂßvèýEº@Xhpl¦ C´ˆ›ÇzƒÉ”çÚ14ò04Š5Q‹èâ-Ný›úݍ
UÀA£1Äl	¾¶°°±z´À?úÂC„ÚLR æÂñîqj»™ÛI_¾€ NЙìH’€ïÆx¥Þd.Ç#Ôò‰Y|ŠÕ©Oœ&ë\Ú€{V¾—ÁAö}.2ËäJ€ç±|0úÀzT>eøøálâ <®Ïƒ¾2
Ïíh–.x@áæà¾+ÙŒIýD1°JÌ^xރg@baÄY-J!ŠpkònÁ!6‡ˆæ‰ÿo¢0˜U§u±BáåÒÈp‹ï`"E80g¸7u-ê;ßNÂ@Ø@ČXŽ¡þÁ—OħŒŠ»@*Ç-v¤T‰•„	¬nXæ(ôp€+œOºãµFžÔgŠoÊÅ¡#B?œÑ›¡KÜý‚*,r˜è3ú€'rxÞÈ°Û´~‚æøbH6ßö=fá
ìƒïâࠀöâ	¢˜ÍI?—i„'gHû<?¼AŠÒ0NpwUµ¾Dܗï
¡<Ü1BežùatWìDÛ՛9Dx
€V6>ƘæšVk8MPÃæႇ`bA³Àì+ƒr–yA¾ãUýðZÎ3O äÞTÄ[½Tr¤‰™çt&8Uu«Ó;|ßeŽû{Ø_’‰ëe„ÓãkC"‘6©ÉŽS×!. x„Q,åû$ñ8\E‹lXąÅJ9·}e‡ôq=
f1žœõåÒÿ˜Îp\õäKÊÍï’ùBj>[Y,QöôÈÔµʓ¨kÒnÓëM7¤wÍ¡$æ¾Wʤœ9^ê\eϓ9¾OÑ.,Ï_«ÿ×ޕv·mdÙÏ®_¨gF¤¢HjsœéøH–ì¨ã­-;Kûxt@a‹(¦§ÿû¼{_Jr'öx’/Dr,‰,ÔúêÕ}ka]eÛ^
ë¾Q	^Bk	b{嫹ð´¬ÈæÓ%$ÏHu“@˜1vOÏ\EJ³j<åvZBÞ\¢Å¼Š,_U¸e>—sB?앨Þ,éLb„'4Q€j“8BL>É8IÐ'áȎé€kã×`Ž·	
=ã×ÓÆ£žÇBÿ/¢E©[ë}þæõۓsO¿T"5aÔ›AaOÎ"ÙýFdO¾/ԍßô+!³RvŠÌU„¡#­e½Â?«d"}—B
ïƈ.l{dvdU |»*$.¥SòåIC×-ېFi4#óæ†ÿùå[¡sôºfyäF¬Ä6R†s½„É[a”.ëbøi¦Òsò
™PÌñ$
Š)	LÄ͚;éòs!#’&¹\d	7<?
¸ê¬(âö„ 
¾j»5Í*p¨¹F*EÍVE<'ŒðÍ
0 +dÏxÑhT—âeG^’Q¹íÐ|âX’á]eÉÏj³–6¾Ð³‚ÿûç_ŸŸ¾ùÂÀ¯àyö,þà?Pü¿7\ãÿßã9®fýѝX?س²ÿçÇ'oOŸý®û°»¿sàò?õ÷{ø¨¿°Þÿ¿ÇóFÀé\ðÒªGvd”P‚"	7‹»ríP¯L1bN- p(‡¤bEL"Zà]@D²Eä$¿[m«õwº`g°ÅÖ{ã‡Æ÷Ô'GŠ¢wZ…†{_×¥àÄ«%­CÙp¿ËøÖ²w\Û¨}ç¾õ	é@>¾åçppëõ[Jd¼kÕõÃýáGm~®YºH}\µ<”ãžƒu»‚DgèM¶µ‰…@$X+le¬~1µé®(šAº|äsy=Yš$È¡Q~™z×öýv]·+ÕTi!lÖËGít Øõ:žU3éHRE¦óöôśóç‡?uEû×ûô¼Ã¤È€ÇÙ{Ñ_
!pžg4§=„Þ›¶Ò⺎ápd#زr»¯¥‘·lµ‹”/ÈÛ4æ=ÖÝäÌj*æheFÂ_ˆÔ¿ÈE*·Šf”p
&Bœ'í#Ys™ˆ$
«Ewƒ¢.®íÙ´h‘×E0òòXސ^Çþsjo”]ˆüÊ¥ÄjÇ(åä:a3’
poÅ`90÷îµl˜¯õý@ˆw×~?°¯ìâûú=A]S Yæ‘ 0	T@Èn°3܂€ÁNÁiî‰\˜Ö¼"¬àÕ¬öÌþµ«¸ç¦ª[ÉÑw«KË#JEvØ Šf9ìì÷”Îa는•Íá¼@¢3_jB¤HÈE*ò±‹­i:‰ÇS7ãouxP˜YEKckµt_´óÂuÌ£zû¤¦æqòžëö&BÈfб ßR‰ú „YˆXV´_°ür%Â
D×Ѹâ´Nãª)1hT9©²Qè4'U"µ¤±HÕº
­Z½ !.öaÃk`+zF‡€ù/™ÍRóe'ԙŒ¢
;ª®„ÎÂD&<:;&óx"r9~G˜:³t-ÓbºM沦Âö#ˆ°3eҖFøÖ«¬J¶¾‹RªB¾j–‰ö¼ÍÜt‰ü
Ç
›ÔÎ9ngпz…Ùåz«éø„V"å1X!4¶ìv’™Ü¤|
ÍMžÉaÂ7
æ.ŠÖ=¤“w
üäÀæ0a.éIÀƒn—«$BœGªg¼B™Èiý\¯kÙrŠàŠÜSݾ1C¶º*Û½ñÈ&“"*· Ý“™QšgÍۄ×:§Ipz´Ë4[È8dǂ˜|PÅõ]äÁLwÛU•¤r¸ÊAa¨¹“-á9æäy°l1WEˆW…‡ýˆÑc»qïN¤¡lÝ[=`ˆ0ûÐ-"´(D%ûNÎÎ0R•p‘!ЁNY3OT5ÌÙuNøÀ4˜×ª'(㕈©{¤Ùâ‘tq3IÒZ
7
#Ýo22è›L‰5ÌŒaEeÑ/©HøŽróI©´ŽOSR˜Ks’ÕL¼3èìì÷ºr¤A¯çP¢Å¥‰uëÂ1ӃòЭ&§Zxæ7úèyÿŠAYÀÁL9¼hÉI‹
rLž–›8¬j‡X…ð«Ó§o_?•¿Ò0!·–eÈɯÇzFrdA‰{{*ì”ó€Ñv։¿ïxA]’î
Jœ—y×pηï{ïþóý»oß¿û¯÷ï®Þ¿+³ùûw£¬,³Ùûw
Îë÷ï =z›¹Ô½#èO~춍1)ºåÛ-þ‡3»Ÿko|¯Õø7¨dHÌû;®ïC9OoWt¤Üä¾~cWÿ¯Cö÷€cûûõ@´Z©UÀbÿ õ±ú€‘â«<KƒO#Mo¨éiÍ
pNÜÀµþ
L:hP4
6Jë
÷ö7‰”¸cwi|è­yzèÁ2fCäµ?ê®!¿³±fãIÇ].²bÓ¢3êë=Ï;C²eX|ÈI/<¢¶qéX
ªVìЀŒæÏt™vÛM»9sm±ž½ºD3°Ž[q‹œÜ@öW2û´Ýk›à2Õ
[+m&ÂÜꎬvüTþ^¡†ƒ•%Ö0vªŽ-­7îN­•¡¬ÊMm2o‹M-:–æ•ü†ÍªÛ&õ
‡Ø3‡Lw£ÜÁù¾­(œ}ÀIAw3kn‚Æ+z¥BL*´ÍÈñ"ߐÛ!·ÔCôº5Â
Mž+ãïa“ê±W0£’F‰àB˜ié@"èù2N2…‡ðzð™j>U!¹É”
\:0cjÛ3Kð2fAõ4s/’wŽ0¼/²,ô­b½çUØÌ€šIŒ¾HÿxáaZ%ìe¥Í„0™•¾”úV"Ìðf§!à«àœAᔋoÌÎ~ûõ/Ä7¾'M
9ï4„fçJ>ûùìÙ˧çÏN~8yvþäðÍá3–õY!ÞxЮžIò8À󱜄i5‡8¿ÛáØ0—˜;"õëyÏ3:di=çÍûœ¿ÁÁó_yö+ž
;žü³ëÙ¨¼•wq\4ssg‘ûiïÜÁAkªp tà`;îz=ph¬¹oƒßñÕïŸøñµtæAß¹VÝÝàʟE¾oÞÉ@ß²’
ØÄêTØüϟL$`*ÿXaw÷l\ù:çãꛆÑNÀ
E’—³ _h3-†Óðg÷0Üpo¬tØ0æºÎ>oV9“°]ÀÔÔHÃa³f„}ãJªXÞo<ŠÇ/ìÀ¨Bx7û5\«­o•*†Ã·ÊÙ`|ô‹6QÛµþõ¿'×þÛÝðåͯo½‰G°P’Áo€ÂüՏ,Ia~vnóëÎ}÷Z£]-ÞðíÊ_͚´ç\Ø`Ï3î™oAöžwRsvÂEaq‚Á$'UNñM‘¹¼eF`/Cô‰0™Õ
vü›+&ÄÛ\YšMK„p‘ˆcRuo8((¡æŠáŽÊsÇL2(}ê„hõ–3ì¹án±ª@Z}…6[˜ÀåèǑ€äŠl>ÆZ#™4Àê;ø— gZW#¡"EÏaFåL-G–+M;řŽîƼ˜f^Tõ@ï)NB
«ý–A±1UÖ¸öE®óMjTGК[ÈbrôÂëÅi4í£Ó¯š‡Ù8|榽îŸ=
á$/R.U~ò'{}T¬S¡>hÀå2ež“·©Ôya+9Á#ȼ
tO˜"Uͧ—V_`DzÏe…Jôp0*àzb-ܐ&ëeÈ#œ÷"™Â…·Qò¨^sgìÜùm©W¦
nšc\%rF«o¤7'õmÈÊ¿M¡I¬à=’,ýÖh=7Zèz¡ÁÕùÒ<€í™Çš;ó‹Ølêšñ=ô¶¶¼yՕªe«v]¡þ¦¨F3¨n8Gê۝rªþÃZêÔPQŒ¤ß„Úœ•:ÿ·otæ-”˼òõ2pj&$1ÓQ‰úܕìë=ï;§ëSíWa
öÏâk$:iŠc,=ïJJÏ҂[ŒC–õò’i+b¨Q
'丐!%œ•pU·*7(@vt’Tïµ}Ñ@‹²»0µ³™a0oõh=ïç¬òT£'ÂÎ%¥
ªZ
^³ý3ëïàæ°bÿž³ñ/ÝƯØÿö‡ýúþŸþ>Ã`gomÿû]ž'Ð#ùÔ"*õ;…ï°÷u-¢(OÚ܎Êñ6#Óòw֙g˜b¦0̐ÂÓH™½eê¡7ŠSå_²›¶«"ßNâTÝÛ|[R{Kæþ-V»ý3½XmEU
g)…6O(Õ«²¡êmé^ßé]û(ó‚ÂÊwûðuVÏ<ËJk•îÓؓ¡Îx.ÌL¸_ív殐ÝzØÒµzw]ZBö æ#7¥ÊyˆÛQ#ÓbS0krÇNá§uIÓ
ë¢ÔãÛvÙö܈·„wVƒNåë:ûþägLö¶,¡LbÇ<Í´ÂÃq!qÉG:dS¯5õ7–¥*·²É–tnk”]Ë!¤„i
2j£€BՉ	Žðä’î‚m[Ñ
¶@È0šo–[øIµµôئ€4gѸµôž#˜¤ÒRëÌdr>dK—-ËsÕãÜ*ØçU^T1ûƒ[YœòÇvÀÍHˆ»XŒ9Îi’„O2ú]&'9¸”ì[,eÈOÊùÃímù·ß;ÙM½,¿ØžW£m;ƒÛ¶ì¶«g5¯cOxWïâcÜ©¤’,S!øÅ4–/d~‘Ë^pÙºS߃Ç¥ŒhHUÃ^/ø7|ð—뫉wgí’ã¹çî
[-¼Z*ü_e
°ÍÕ³òmoÛm†hås*ÄäcN/ÒL-‰îê5/¡€–ŸÙf¡²–ú
b-#ÜA+à"ÇV—/[H
Ô
82Ò¤ï¬8Âaqä]¤~éìßzŸR—¬‰Ì$ZÐבî¤0N\¨=;H/¥ftâ+¥¢³(²ÙÜkúyù½’Ðê<À~o>÷B%óY'™ß|A’W½
½\½ɸKŽÌ§]fd~û¥Eæ‹\a`>ù"sS–_½lÈ|ê¥B«íšßpIÐÇÞÿµË€ÌÇnüùX…+7û˜O¸ÁçcÞySùÕyÌç_¼r£'¿vÁŠÑÝúDmùÜ©€ÕÃ
Æ^;boj°Öæìf!o"Œwr0ŠÈ¢™œ¡ã~oþeRhs+§(ªyH*ùÍÙ)Í͈^®i+¦·ß
éÝï›&<w¡ÝWŽt¿ÆXÔ;zOO^œ¼>}ü§ý½/Þy°oª8üK¿ƒ~vE6Çï"¸EIW»‹úoßv.Eâ•_v:ŲŸ»áÕ"?îuTTÏr”êwLL&(7è\
¬¾k}-ˆª`ñ¥h܈™LR„kãY½Èª
˜L²ô
AY*Ò 
ͯtío<ÞѳÓÇÞÉO¯ž½<}søæôåïåà´cïøðä¹üyû¥ú¡GDmف´Uô°ç"ø'$Öx±ºþÀB»fô¼ãH–—VU)z¶ýý
sªÁ"”WnÑ­ŠÅ:¯ÔáŔ6…÷)ÕÒ÷A«k¿ë×72ñzˆÃ±³%‹+°õ€0°Sì
|H	 Kù°i8båAYÚÍs
;ëñд¯¢„º48L—t0w
uÓX :T5õáæÙk \¯ÙÅpÚA'V§WãðVd'Ç!ëؠǗ”KÒ7evA9‰-ç{Lǟ	›§rÈÆ¡‡œï3Ç%bFgY'¨Šé–©“—¼”$]x@̳s»‘%Cêš
*àÿ`-õ:mÊ±†mÂipäaµoՉ†Y$³ZÀë®Ò“17™™…¯è[͐>‘“}
»3kªy…á…Þ'‘BsØ(-r=VÉ%™õïj¢û¯‡ä6—Lyœ’&>‹U·ßýí­³»Ú×»_tÔ;½»NX=ÖHl¿Ôüፅ_Ð÷ÑdŠÄ•ò’iŽ{՞ªg^)Âú,.;¯Ÿ>?üê-eî7Îwt('M„xO:y,KïJFAj®iz©L;¢}Wd:_žê&º¾µ«ÀC¡fø­·3%ê„GŽ¯»]„ºyVDµ¯L3õ¦I"¡1õvº¡î¿iB¨uòø%ZWún…¸öt*£ÔmY§xAx²•;TKN]çã8S6‹ÅÙÅÀÒãŒÓØÜTcp šã|U8¶É‹uÜ©ÔN­Œ5´*éoNÇ ï[×Y0¹ºÜ:’4O-ëfDÒq­¸iéQ¥0M'溷ÛÅדÃ×(Š±&°œ·õ6}¸ÊF<£ô´YhAÿnÛ£-yðS…C»În·˜]šSç³­Â"vFóÒnȌ=Q:fd{©¨‰®Àr~0ð[ä~8³
ö)îáüõY
˜e÷OwßÛ}øÈßCùp_>ڑOô-=)œ3Bhš=øÁíAcÎädqÒP“/¨9:À2Q"§§=4?Clfµ¥wå-Sn
:
ÅáàÆFˆ9Aõ¤òИ;Yä9€ð*›$w–æ¤ÌÂ缇yûœ÷0ÓÒQÀOÇó$5¥ê®pâWÊn®?-ÛÄFóBk#ÖælBÚ²¬_xÍÅàn×ìÊ»wb‡îU7M,
dR3^Ì(yo$ý]Ä¡ˆ0¦`ÿ<þ‹å¬ºÉt›-º²ƒS
Új÷:¸ü^Ï{!oçֈ;5‘uµsŠ/Z·bh,xF$Ryé†uy[D­Ùƒ{.dgùåt‡ÁÊê#Uk¼tþ£µ½¦‡kþT­˜ŽéŒ{pö87X G@›ÂUåí¡¿‡&Nâó£ýȘӲåw
nž+Pƒß+c–5ô¿15æéYN¦¥Si,°r!=]Õ£û§•)¨oì™2„Ÿþ<h1,¢_Ë^­bM3^5¬õʄ³¼ˆh<ríkT7c3rY<#£Øë{ô¹•A–XÙ7Vz±A:ÛÀ¯ÅfåÞ½T
ýÞ½{¤÷{ïä·÷ï¶o>[x¾}C¦Æó?7þ4[áê';´ù¬|°×7ŸÅ_@Uç8PÎw¡+aE_¢š~_-ò›¼m.™µµraã¢6ÆH‰@Íň‡
!Ü@GmB(²¥ß¶éÛ¸æ˜"©÷’¬÷†5JÆX³úìȬÙ·?ÔÍZ¹l~j8{÷MG
³ñ
›²FGtJ+`._IG×â5rèÃ~Rar¦qÉ<>ïÌtã–æòÙáљK~qCYdShÌH£%à«&“±nçÑ]‚‚R
ÄË}……-¾¦N|`Ó[aÃÍRF¤Í2kx©‘m͗nŸŠôvk3ÀÜk 
"¸cÊ[,?-ÉÐe#ê^!G²ÚåíšìùmæX‡²˜ý¾ãRVÆô¼—ÀK‹éy•®K\½¸”ÉùÆ©£?q[ܽ'¾@˜ÆT%¼fzü?+öÿÝó£g‡ß}ñ6~Íþ¿·7pöÿÁþ;{ý½µýÿ÷x6­"Ê;œ-²@ù
]ᄆ=ŹˆG®Øãð–“RÓ/¢Æ„?vE'òëZ½Äxì¾?ŽŠYF蝣™:fEZK"aà=s⊞
ÅRɺÆSçNxsȖ¾÷Ä{¤©´PTÈ䅂ñàª$R|4–ÚžºbO£LN7)7£€eæ3)™W·¾s律€É}U•™£²rZ]ôÌ©+sìV˜kž뇗—ÒÀ_]©¿"G˕Yvé%K„G-½Y,ózõÌ÷®à÷PôÙ)Sç¸K{Ëx¯å­g®ä³(cÁç
ÏÄøxЭÊ"<wŞUØT¸ˆæ%'Zã±|ï…+÷"º’õäHbÍÔ¥UÜ3/]—I|%íçUZàëŽ-ß{å
¾ÊãPæT`†p—²á££\
š¿¹r«p_{ªƒÒK-4‹:öÚz=ÍÂÀ¯3Béàôï™3W欒×YÍ<Ècd(Sˆ€tÅo\¡7"}é
L’ha¯Š§9ÿ­+ò6
<íMÏç  e
KĂ¼~på~ˆ•,Šÿ®¶æ¨ÙÒDÈüÑü1NcL$¨)•6ä ÷E°~Šò1£ÂèJBßLÊôÌÏ®ÌÏHøƒnô]
¹#mÝú»+ø÷8I-b:J@7TÝ·Ðù֖wò–ô§Y.gôôBOe£
ˆ{œғ)“M·aÌs٤ظ­ä«Ï›¡¯–•Q#3Š!BÖÃ'$­è’ùÆèkxÿÙà"Ãåè•ÕƒËš0ú´CÅêLG3ÐïZºQÂu™”Åÿ6˜G£”[5Îæˆ|Ôꀖà¸D7…•	,÷”˜,&•õ¹bdªÍÑTLãyWQ²C­ÑL¤xtvåuœ
âS¥ÌéÙ\A§W§H&u.GgÇHš Ìpfá9ï ͎æy‡_G×ÒÀ¼ldmFle £Hs%Ü°ÿb›Ò0—E§g%Ñ#Ï{'=”~Eá{*mDmÈØPsÏS·+Ã×݆Œ
m—0ì-Ž£ÚˆDŽqJ5WÔlV¥XØ92l	†ØXͪME‡/?0÷Ÿ0+©BUÔx«({ȾȜÒçR™(¬ˆòxNø*\éª%5ԓ¥UÙ¬sªiar±jôAø¸b홓ùƉ-¤
ê?¤³ÛÅ8H搰cDÜÊ¦°dšƒÏ†±Ï¨
°êÖÞg˜|Íçóúpäø–}c}ênš­ŠÏÒ	œc‘´úýÔ«ƒGAó#=d䝾~ìtPm≭vÈ.0³aW}\Ž{0©cÖõ‚?L¡ý9R‹÷º^œ7wX٦ᨒF6ùÚøªh;#	•:é’îÌ£ ¤^o-loí1X‚Ï"֓Öé°h‰+¸ï嘈'õ5„2d¥gŠK2Cê7C¾ÎØ:-»7!5†Y–k¸4âìºè¼Ùéz/Óv—.¢4¦Ý‚	ÖÎ2øbAJ½Ž„30¾N[ˆT{‘żѳ
˜—neâ$P7ÀHõd’NÃ8ƒª€M$ã`VV܏aŽ„°´֎j¤Dšc¦õ˜ÐK95‰Ôå(hMM¦—Â…d™˜.Ý®àEÎ+Ùe‚N_=–n<–#¤“s–j‰„¨ƒÚ÷–GÐð±ÓÐxåàÚGÏÕ¨Šcè§d=b
¹©oã12xì2ujB~‘-|"­˜GüSX
Rçã¡a6·Œî8é¹Ý4\
d«.W Ç*0ÚTèb¹Œ ä$6U"Éò噐g
—µÖ!f*çmâIZ ¹¡Ye9öÍTŸ4nk¤PN*FP´kòûhÆÎ!†Ö)1ÄÙz`ùöˆl‡,¡¦çâÇ3A81}ÿ·¤Å’T¦ÞöԊÀ1î¢ÆÚÛsU%«Œk®-D¤ZnMój¹tÈíÎ0Iø®éúіáÞ±ª0¦[œÅ¥ón;ħÞ}ìÅ(âQ¥¼3gÔÏmOÝÂWµ)`ÎéÆ4և‰ì„Çp
ÂH
kR	Èg™:ˆâ={00'2†ÈçÒ;"=ž̹x‘!UFÆ
eM©j÷oœbõ¥¡I
X×|H–Tº@Öññmvy FJb¨hñ
7ÕñOnB¼—Î.`^—¤¢f¾ªxÕH<°þ_y"¬È¸
Á´mE)£sèÈ°!C|Øð쵙Îl•ZmõJ·:ÒhÈ>B˜qJ»Ê4ÖF˜vX¿*Á½b6èÔ³Io!cÛ8µ†º"SŽé^°Šm¼+ßð$È[BèÚTã«»RÓÐÐ+÷Æ\Zå^8ûhƒëšôéð@T‹©/Sô:‹ï
ã\äKÍ£à˜~f#Õ®|͍óØ4žÁµ0Ëå%Aôfaõ7¢¡š:n¸ó»#eI”ª³†w•:µýS‚f
á„N˜4ÛyåcZ¡®Enœ%3oõ°úÂã•Kf=ÈY?žÆ²}˜:Wúݹõ‰ËŸ1¢pà2õ¨\|å7iv§ÌkR8=uËM²1ÏÓ,í*ÿ²ç‰–Ú°çÃF­ØFöå¥oƒ°,d	YU-×Ç5L0E6©*|`î\UI_ÆôTw"„¡ÇÂú°Zz0Ø%­zà^ºvˆæÄæYC«/-…ÜHÌ\+Á9v«¼ˆÔ‚¨³R–Žóò¦“ôƒööFäñis&¬“¤¶Å¢'8î	rO{ª½TèxûE„”<¯òì*ÓÃþXÞñÎÒx2¡3N+Ðñ|
yÝX
Ú
\
çNîS`ûO÷ézå­g0s„`Þì^¨}q›•.£ñ4EÊì%AÈ¥¼Œ¡â@U{fO¾–™Å@ۏOߜÚÌꞛ–v†p‡f
¸â+ÚÒoç÷¨,ã‹'gMYwNOÞ<i>©ÎëyÛž†6
ËyoúPؘg4yè½Ôd@­Ôùµ=çdsôóˆ¡ÌJèd“
9”Âo¤nY:Ó؆_Yþ»°Á¡vJœd«®ñqçþ¢-ZωGÆ<Í5Ü"ó~ˆ/5¤¸›^Ä
-j|âHT¥|",·íä(µœá<¡ÆŠÚfã¢ÝrÞÏ”éDoÃc%àÚ·Šò^Zyn˜<çC5|âËXÄTf¡o­­¿q4gr· §UYÕ~žÚP
2E?7;’¶zƒŽ /`òü¬cG*$ëpdiVD’!è0«F"’y0k3­ùçM
2°~©Ý
xÔ¢¦*9îéµ9Ínì}ºn,›Óㆀ2…ÆWƒÝ:w~M(Ï×.#Áòì£stÒ'*Ö­¡“O£’©QË·ËÆõK”nñÆGÈ{ÈҁÔTQžu]»™Æ
Ówlng±æ–YHÙI¥ëÄ}ù,øN!…P±l)f`K¸‘®ä(ÉƗM ·Êé.
•«Z1AñÌg¯sê!ˆ9A3ÄÌ"+kÄÕð¼(ÝÓª­p²É¥ Å±¾–ê3àÀ»
î5ڃ¸©áþ®~
1OUaѐ²(ÁzrPG.]œÚm
€5à$E¶e᲋Ø&C©=STÖ´³vf…wÄ ëØA+¾°·FԡۍAﲪPhþ¤¯0.®±„÷̽a×;Ԁ)XB™.EªëMåLæ§Z¦¿ ê6€È7<—w5Ö
ÎŒ}#eéê܈µu+"=ØÁ°¢ñ㧧v{ÈAbíõE™Íçj7ÞH³|$î’
†°~vÀâHù„Ç`7¢JNý$|¹`ÛÍêÚ=b?:6aÝøô–ŒšÓok֞:Þ¹G†Ìlˆ<«h¼Ü´ã”v»ôw¡?ÁT8¸HSY
Aõp<¥Ã2=M‹Fôu½G§(
°Ál¥Œ[¯‘sg>Å­\Eì×g o]T{Ñ%†œ-S}ŒVbÀÜ°0M:4†xè89….4UQ(ÛÉ
îu½#ظ²
䒇i¦9ûºW±÷
ëéÜêШHöªoxasLêPZ
„‚R³Qs"r)ÇE»»üÂ*CŸ[Ì$ãO
¬~ew$uT˜Z@µ5Žá™@
üñ ¦Ì!hRuk¾µ:á¢F<Sïp!©?Á¾0×¥åø°g,„ÍÃ	Ö§
'QÒ¨0‘“,nBa±²kÂqjƒÆByi
ÒyVÆE<ó­¤Ema†ÞE1«Ššޞy¯ôüO7ÚU<ÑÔ”nÔÐæɁ­¼3ÌòK{B„™îL¢
ê§>d#*³D“ úSœ7YQ
¦'€Ÿb°,Z§#=_ꌂ+:«q…±:W\ÿâ!å–Õ×ÖãåÉ­~=õºøúž0©£cºhšÇ&¥öIõFrMaÒq$˜ÀòTFw„œ½µ£ÃúY?ëgý¬Ÿõ³~ÖÏúY?ëgý¬Ÿõ³~ÖÏúY?ëgý¬Ÿõ³~ÖÏúY?ëgý¬Ÿõ³~þ¿žÿ
2à\È
(8672942) /<gobbles@hushmail.com>/--------(Ombruten)
8672943 2002-07-01 10:32 -0700  /9 rader/ <gobbles@hushmail.com>
Bilagans filnamn: "sshutup-theo.tar.gz.sig"
Importerad: 2002-07-01  21:49  av Brevbäraren
Extern mottagare: submissions@packetstormsecurity.com
Extern mottagare: vulnwatch@vulnwatch.org
Extern mottagare: bugtraq@securityfocus.com
Extern mottagare: alan@redhat.com
Extern mottagare: jesus@jesus.com
Extern mottagare: dugsong@monkey.org
Mottagare: Bugtraq (import) <22904>
Bilaga (text/plain) till text 8672941
Ärende: Bilaga (sshutup-theo.tar.gz.sig) till: Proof of Concept Code for OpenSSH
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: Hush 2.1
Note: This signature can be verified at https://www.hushtools.com

wj8DBQA9IJEkHNGnlyGZsA8RAsYLAJwNvZG2kXah2pYNPzFdhQqk4KrSwQCfZVyu5ors
rveeC4DKhT1jb+LwDFs=
=x1BX
-----END PGP SIGNATURE-----
(8672943) /<gobbles@hushmail.com>/------------------
8673452 2002-07-01 18:30 +0200  /202 rader/ Markus Friedl <markus@openbsd.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-07-01  23:37  av Brevbäraren
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Mottagare: Bugtraq (import) <22907>
Ärende: Revised OpenSSH Security Advisory
------------------------------------------------------------
From: Markus Friedl <markus@openbsd.org>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20020701163017.GA23430@folly>

This is the 4th revision of the Advisory.

This document can be found at:  http://www.openssh.com/txt/preauth.adv

1. Versions affected:

        Serveral versions of OpenSSH's sshd between 2.3.1 and 3.3
        contain an input validation error that can result in an
        integer overflow and privilege escalation.

        All versions between 2.3.1 and 3.3 contain a bug in the
        PAMAuthenticationViaKbdInt code.

        All versions between 2.9.9 and 3.3 contain a bug in the
        ChallengeResponseAuthentication code.

        OpenSSH 3.4 and later are not affected.

        OpenSSH 3.2 and later prevent privilege escalation if
        UsePrivilegeSeparation is enabled in sshd_config.  OpenSSH
        3.3 enables UsePrivilegeSeparation by default.

        Although some earlier versions are not affected upgrading
        to OpenSSH 3.4 is recommended, because OpenSSH 3.4 adds
        checks for a class of potential bugs.

2. Impact:

        This bug can be exploited remotely if
		ChallengeResponseAuthentication
	is enabled in sshd_config.  This option is enabled
	by default on OpenBSD and other systems.

        Affected are at least systems supporting s/key over
        SSH protocol version 2 (OpenBSD, FreeBSD and NetBSD
        as well as other systems supporting s/key with SSH).
        Exploitablitly of systems using
		PAMAuthenticationViaKbdInt
	has not been verified.

3. Short-Term Solution:
	
        Disable ChallengeResponseAuthentication in sshd_config.

	and

	Disable PAMAuthenticationViaKbdInt in sshd_config.

	Alternatively you can prevent privilege escalation
	if you enable UsePrivilegeSeparation in sshd_config.

4. Solution:

	Upgrade to OpenSSH 3.4 or apply the following patches.

5. Credits:

	ISS.

6. Release Process:

	Information release was handled in the following way:

	a. We alerted the community via a number of news sites and large
	   public mailing lists that a major security issue was coming,
	   and that they should upgrade to OpenSSH >= 3.2, and enable
	   UsePrivilegeSeparation as soon as possible.  We also released
	   OpenSSH 3.3 at the same time, without a fix for this serious
	   new issue.  The goal was to place the community on a security
	   stance.

	b. We could not alert the community that disabling
	   ChallengeResponseAuthentication solved the problem, since
	   this would highlight that the bug is in about 500 out of
	   27,000 lines of code.

	c. We could not alert the community that the bug was SSH2-only,
	   and tell them to disable protocol 2, since would have focused
	   the problem in about 5,000 out of 27,000 lines of code. (And
	   we did not think of this possible solution until after ISS had
	   released their advisory).

	d. We did not tell people which versions were vulnerable, since
	   the 2.9 to 2.9.9 transition was largely a rewrite of the
	   ChallengeResponseAuthentication subsystem.  This would have
	   highlighted that as the problem area.

	e. We believed very strongly that the issue was unknown in the
	   Blackhat community at the time.  We also made the decision based
	   on the subtlety of the problem.  Finally, we believe that the SSH
	   protocol is a security infrastructure protocol (with DNS and BGP),
	   and that issues of this scope require more gentle care.

	f. We did not alert vendor contacts with detailed vulnerability
	   information, since the list of vendors who include OpenSSH
	   numbers around 80+.  We were sure that any disclosure would leak
	   very quickly.  Another vulnerability came to our attention at
	   roughly the same time (BSD resolver) and started leaking within
	   5 hours of vendor notification, so we tried to be very careful.

	g. We did not have a complete list of vulnerable systems because
	   ISS did not do very complete testing, and we did not have
	   access to all the systems to test on.  Even so, we would not
	   have wanted to alert the vendors as to which are vulnerable,
	   because they might have figured out their configuration options
	   and leaked the information.

	h. Some vendors were initally upset by this policy of non-disclosure,
	   largely because the UsePrivilegeSeparation code was only about 90%
	   functional in OpenSSH 3.3:

		- old linux kernels needed Compression disabled
		- extended Linux PAM did not work (but that is where
		  the ChallengeResponseAuthentication bug was)

	   Over a 48 hour period, a few of these vendors rapidly helped us
	   to get these problems resolved, and we were able to release
	   OpenSSH 3.4 which solved these problems to 99% user satisfaction,
	   on almost all systems.

	   The most helpful vendors were OpenWall Linux and Debian.

	i. ISS suddenly insisted on an early release of their advisory,
	   4 days earlier than ISS and we had planned.  Some of us were awake
	   for 37 hours to get OpenSSH 3.4 out the door with the fix, at the
	   same time as the ISS advisory.

	j. We contacted CERT, and they released their announcement of this
	   issue in record time -- around 24 hours.  Dealing with CERT and
	   ISS took more than 5 hours of telephone time.

	k. We have received mail from many users, including large and
	   significant organizations, who were able to take a security
	   stance by following our instructions about UsePrivilegeSeparation,
	   disabling OpenSSH, filtering port 22, guessing at functional
	   reduction, or preparing themselves for a new release at any time.

	l. We have not heard of a single machine which was broken into as
	   a result of our release announcement method.
	
	m. The first public attack program for the vulnerability was posted
	   to BUGTRAQ within a day after OpenSSH 3.4 was released, apparently
	   having been written based on the bug description.

	We feel that this method of releasing served the community
	best for a "contained" vulnerability of this kind.  We do not
	suggest this is neccessarily the correct information release
	process for all problems, and as firm believers of full
	disclosure have never suggested that, though we believe that
	disclosure must be carefully handled.

Appendix:

A:

Index: auth2-chall.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/auth2-chall.c,v
retrieving revision 1.18
diff -u -r1.18 auth2-chall.c
--- auth2-chall.c	19 Jun 2002 00:27:55 -0000	1.18
+++ auth2-chall.c	26 Jun 2002 09:37:03 -0000
@@ -256,6 +256,8 @@
 
 	authctxt->postponed = 0;	/* reset */
 	nresp = packet_get_int();
+	if (nresp > 100)
+		fatal("input_userauth_info_response: nresp too big %u", nresp);
 	if (nresp > 0) {
 		response = xmalloc(nresp * sizeof(char*));
 		for (i = 0; i < nresp; i++)

B:

Index: auth2-pam.c
===================================================================
RCS file: /var/cvs/openssh/auth2-pam.c,v
retrieving revision 1.12
diff -u -r1.12 auth2-pam.c
--- auth2-pam.c	22 Jan 2002 12:43:13 -0000	1.12
+++ auth2-pam.c	26 Jun 2002 10:12:31 -0000
@@ -140,6 +140,15 @@
 	nresp = packet_get_int();	/* Number of responses. */
 	debug("got %d responses", nresp);
 
+
+	if (nresp != context_pam2.num_expected)
+		fatal("%s: Received incorrect number of responses "
+		    "(received %u, expected %u)", __func__, nresp,
+		    context_pam2.num_expected);
+
+	if (nresp > 100)
+		fatal("%s: too many replies", __func__);
+
 	for (i = 0; i < nresp; i++) {
 		int j = context_pam2.prompts[i];
(8673452) /Markus Friedl <markus@openbsd.org>/(Ombruten)
8678723 2002-07-03 01:40 +0000  /49 rader/ Charles Hannum <abuse@spamalicious.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-07-03  08:12  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22930>
Ärende: Three problems in OpenSSH's ssh-keysign
------------------------------------------------------------
From: Charles Hannum <abuse@spamalicious.com>
To: bugtraq@securityfocus.com
Message-ID: <200207030140.g631ess20085@nagasaki.sitaranetworks.com>


[This is being posted to bugtraq in the interest of full disclosure.
Originally sent to markus@openbsd.org.]


There are 3 problems we observed by inspection of OpenSSH's
ssh-keysign:

1) [Charles Hannum] Since no blinding is done on the RSA calculations,
   ssh-keysign is effectively a fairly efficient oracle for mounting a
   Kocher timing analysis attack on the host key(s).

   (Using OAEP padding -- per recent versions of PKCS1 -- would not
   only mitigate this better, but would also mitigate other RSA
   attacks.  Unfortunately, this would require a change in the
   protocol.)

2) [Bill Sommerfeld] There is a use-after-free bug; see:

        if (valid_request(pw, host, &key, data, dlen) < 0)
                fatal("not a valid request");
        xfree(data);
        xfree(host);
        ...
        if (key_sign(keys[i], &signature, &slen, data, dlen) != 0)

   (This has already been fixed in the main OpenSSH tree.)

3) [Charles Hannum] The protection of host keys is not very good; to
   wit:

        key_fd[0] = open(_PATH_HOST_RSA_KEY_FILE, O_RDONLY);
        key_fd[1] = open(_PATH_HOST_DSA_KEY_FILE, O_RDONLY);
                        
        seteuid(getuid());
        setuid(getuid()); 

   Although current BSD systems are safe (because they do not permit
   PTRACE_ATTACH, et al, on processes that were ever set-id), this may
   permit direct reading of the host keys by users on other systems.


Have a nice day.
(8678723) /Charles Hannum <abuse@spamalicious.com>/-
Kommentar i text 8678806 av Theo de Raadt <deraadt@cvs.openbsd.org>
8678806 2002-07-03 00:11 -0600  /44 rader/ Theo de Raadt <deraadt@cvs.openbsd.org>
Sänt av: joel@lysator.liu.se
Importerad: 2002-07-03  08:38  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22931>
Kommentar till text 8678723 av Charles Hannum <abuse@spamalicious.com>
Ärende: Re: Three problems in OpenSSH's ssh-keysign
------------------------------------------------------------
From: Theo de Raadt <deraadt@cvs.openbsd.org>
To: bugtraq@securityfocus.com
Message-ID: <200207030611.g636Bv8I029860@cvs.openbsd.org>

> 3) [Charles Hannum] The protection of host keys is not very good; to
>    wit:
> 
>         key_fd[0] = open(_PATH_HOST_RSA_KEY_FILE, O_RDONLY);
>         key_fd[1] = open(_PATH_HOST_DSA_KEY_FILE, O_RDONLY);
>                         
>         seteuid(getuid());
>         setuid(getuid()); 
> 
>    Although current BSD systems are safe (because they do not permit
>    PTRACE_ATTACH, et al, on processes that were ever set-id), this may
>    permit direct reading of the host keys by users on other systems.

First off, we believe that any system which has weak handling of such
setuid or setgid processes is flawed.  But let me continue before
anyone freaks out at that strong assertion.

There is a tradeoff being made here.  Either

1) We continue running as root, any exploitable bug in any code after
   that point can gain root.

or

2) We drop root, and any bug after that point can gain those file
   descriptors, and those files.

We choose 2.

That said, we very strongly believe that any system which does not
have strong de-permit semantics for ptrace and any other such calls
will continue to have serious security problems in the future.  They
force application authors to keep large monolithic processes running
entirely as root.  This is not a sustainable or safe policy.  Time for
vendors to start fixing those systems, if they are not already fixed.

This way, we do not need to keep very large applications like ssh and
sshd running as setuid root all the time like ssh.com has to.
(8678806) /Theo de Raadt <deraadt@cvs.openbsd.org>/-
8682211 2002-07-03 20:21 +0100  /195 rader/ Global InterSec Research <lists@globalintersec.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-07-03  22:01  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: research@globalintersec.com
Mottagare: Bugtraq (import) <22946>
Ärende: [Global InterSec 2002062801] OpenSSH challenge-response buffer overflow (Update)
------------------------------------------------------------
From: Global InterSec Research <lists@globalintersec.com>
To: bugtraq@securityfocus.com
Cc: research@globalintersec.com
Message-ID: <4.2.0.58.20020703201612.039fa6a8@193.133.49.25>

Global InterSec LLC
http://www.globalintersec.com

GIS Advisory ID:     2002062801
Title:               OpenSSH kbd-interactive buffer overflow
Changed:             07/03/2002
Author:              research@globalintersec.com
Reference:           http://www.globalintersec.com/adv/openssh-2002062801.txt

Summary:

   OpenSSH, a popular server utility that provides encrypted
   connections between hosts and is commonly used for administration
   and file transfer, contains a integer overflow, resulting in a
   heap overflow that could be exploited to execute arbitrary
   commands.

Impact:

    A local user may be able to execute arbitrary commands as the
    user which the OpenSSH daemon is running as prior to
    authentication.  This is normally root.

Versions Tested To Be Vulnerable:

   OpenSSH versions prior to 3.4

Description:

   It is the current belief of many that exploiting the recently
   disclosed vulnerabilities in OpenSSH's challenge-response routines
   is reliant upon a system's use of BSD's authentication mechanisms
   and therefore restricts the platforms on which this vulnerability
   may be exploited.

   This is almost certainly due to various advisories posted to
   various fora by unnamed security companies.

   Although it is widely known that all systems running versions of
   OpenSSH prior to 3.4 are affected by this vulnerability, many
   vendors have deemed their platforms invulnerable to exploitation.

   In spite of this, our research has proven multiple platforms
   originally thought to be invulnerable to attack to be vulnerable.

   As reported by GOBBLES [1], systems running vulnerable binaries,
   built with --with-bsd-auth at compile time are vulnerable to
   attack via an integer overflow in the
   input_userauth_info_response() function.

   Conversely, under Linux and other platforms using a vulnerable
   version of OpenSSH compiled with --with-pam, the integer overflow
   lies in the function input_userauth_info_response_pam().

   In both cases, the final heap based buffer overflow is a result of
   the integer overflow of unsigned int nresp, calculated from
   packet_get_int(), the return value of packet_get_int being a
   client controlled integer.


Scope for attack:

   - Because of the nature of the vulnerability, exploitation is
possible  before
     a user has authenticated with the remote host. This would
potentially  allow
     an attacker to remotely execute arbitrary commands as the UID of the 
daemon
     process, PRIOR TO AUTHENTICATION.

   - To exploit the vulnerability described in the "Proof of concept" 
section of
     this advisory, the sshd binary must have been compiled with PAM support.


Work Around:

   Global InterSec recommends the following settings be disabled
   within sshd's configuration. This is normally located at
   /etc/ssh/sshd_config

   PAMAuthenticationViaKBDInt no
   KbdInteractiveAuthentication no

   However, we strongly recommend that all vulnerable binaries are
   upgraded as soon as possible. (See vendor solutions.)

Credit:

   All information contained within this advisory was independently 
researched by
   Global InterSec's vulnerability team.

   The original PUBLIC disclosure of this vulnerability was made by 
Internet Security
   Systems [3].


Vendor Solutions:

   Since the original disclosure by ISS [3], vendors have released
   their own advisories, with distribution specific fixes. A list of
   some of these follows.

   Mandrake Secure Linux:
       http://www.mandrakesecure.net/en/advisories/2002/MDKSA-2002-040-1.php

   SuSE Linix:
       http://www.suse.de/de/support/security/2002_024_openssh_txt.html

   EnGarde Secure Linux:
       http://www.linuxsecurity.com/advisories/other_advisory-2177.html

   Conectiva Linux:
       http://distro.conectiva.com.br/atualizacoes/?id=a&anuncio=000502

   Caldera Linux:
       ftp://ftp.caldera.com/pub/security/OpenLinux/CSSA-2002-030.0.txt

   NetBSD:
       ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2002-005
ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2002-005.txt.asc

   Redhat:
       http://rhn.redhat.com/errata/RHSA-2002-127.html


Exploitation / Proof of concept:

   On certain distributions of linux, the evidence that this bug is
   exploitable may be more apparent than others due to the %edx
   register being overwritten.  In either case, slightly more careful
   inspection confirms the possibility that this vulnerability could
   be exploited when compiled --with-pam.

   By examining an assembler dump of
input_userauth_info_response_pam(), we  can
   see that the (corrupted?) %edx has been loaded from 0x8080130, where 
0x8080130
   is the location of the context_pam2 structure.
	
   0x80521f2 
<input_userauth_info_response_pam+122>:       mov    0x8080130,%edx
	
   Note:
     The above instruction to mov 0x8080130 into %edx occurs in
preparation  for
     the call to xfree() and after the call to wrapped strdup(); whilst the 
debugger
     back trace suggests that the xfree() [free()] was never called.

   By allocating specific break points through out 
input_userauth_info_response_pam()
   and into the call to free(), it becomes apparent that the call to free() 
could
   be exploited:

     Breakpoint 14, 0x0806c677 in xfree (ptr=0x808a380) at xmalloc.c:55
     55              free(ptr);
     (gdb) print 0x808a380
     $24 = 134783872
     (gdb) x/10x 0x808a380
     0x808a380:      0x41414141      0x41414141      0x41414141      0x41414141
     0x808a390:      0x41414141      0x41414141      0x41414141      0x41414141
     0x808a3a0:      0x41414141      0x41414141
	
   From here on, exploitation becomes trivial. For more information on 
exploiting
   calls to free() see the excellent Phrack article "Once upon a free()" [2].

References:

   [1] GOBBLES Security - 
http://www.immunitysec.com/GOBBLES/exploits/sshutup-theo.tar.gz
   [2] Phrack Magazine - Once Upon a free() - 
http://www.phrack.com/show.php?p=57&a=9
   [3] ISS -
http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=20584

Legal:

    This advisory is the intellectual property of Global InterSec LLC but 
may be
    freely distributed with the conditions that:

    a) No fee is charged
    b) Appropriate credit is given.



(c) Global InterSec LLC 2002
(8682211) /Global InterSec Research <lists@globalintersec.com>/(Ombruten)