--On June 6, 2006 4:32:02 PM -0400 "Steven M. Christey" <coley (at) mitre (dot) org [email concealed]>
wrote:
>>
>> Yet know we're getting "security advisories" warning, hey, if you
>> change the defaults and ignore all the warnings, you too can write
>> insecure code!
>
> In this sense, I agree. Default configuration is one thing, but
> active negligence is another.
>
> That said, Squirrelmail apparently thinks this issue is important
> enough to release an advisory:
>
> http://www.squirrelmail.org/security/issue/2006-06-01
>
> So maybe they know more about the implications on their consumers than
> we do.
>
Did you look at the patch?
It's almost 40 lines of code designed to *force* register_globals to "off"
no matter what the idiot behind the wheel does.
I understand that there are many shared hosting sites that have
register_globals set to "on". IMNSHO opinion they are putting their
customers at risk unnecessarily. The default setting should be "off", and
if someone needs it turned on in the application they're using, they can
turn it on there and assume the risk themselves.
It wouldn't take much for web hosting companies to educate their users. A
few lines of advice on a webpage would suffice. For example, for Apache
users, you can set the php_flag register_globals on/off in a VirtualHost
context (inside <Directory>.) So the hosting company can enable it on
request but use the proper default setting for most sites.
Or the individual webmasters can set php_register_globals = [on|off] in a
.htaccess file (Apache 1.3.x only!) or php_value register_globals [0|1]
(Apache 2.x only!) if they don't like the default setting the hosting
company uses. Or they can simply include a file with the setting in it and
add an include statement to the code of the app.
I'm sure there are other methods that could be used as well. Since there
are many options available, the default should be secure.
wrote:
>>
>> Yet know we're getting "security advisories" warning, hey, if you
>> change the defaults and ignore all the warnings, you too can write
>> insecure code!
>
> In this sense, I agree. Default configuration is one thing, but
> active negligence is another.
>
> That said, Squirrelmail apparently thinks this issue is important
> enough to release an advisory:
>
> http://www.squirrelmail.org/security/issue/2006-06-01
>
> So maybe they know more about the implications on their consumers than
> we do.
>
Did you look at the patch?
It's almost 40 lines of code designed to *force* register_globals to "off"
no matter what the idiot behind the wheel does.
I understand that there are many shared hosting sites that have
register_globals set to "on". IMNSHO opinion they are putting their
customers at risk unnecessarily. The default setting should be "off", and
if someone needs it turned on in the application they're using, they can
turn it on there and assume the risk themselves.
It wouldn't take much for web hosting companies to educate their users. A
few lines of advice on a webpage would suffice. For example, for Apache
users, you can set the php_flag register_globals on/off in a VirtualHost
context (inside <Directory>.) So the hosting company can enable it on
request but use the proper default setting for most sites.
Or the individual webmasters can set php_register_globals = [on|off] in a
.htaccess file (Apache 1.3.x only!) or php_value register_globals [0|1]
(Apache 2.x only!) if they don't like the default setting the hosting
company uses. Or they can simply include a file with the setting in it and
add an include statement to the code of the app.
I'm sure there are other methods that could be used as well. Since there
are many options available, the default should be secure.
Paul Schmehl (pauls (at) utdallas (dot) edu [email concealed])
Adjunct Information Security Officer
The University of Texas at Dallas
http://www.utdallas.edu/ir/security/
0?ì *?H?÷
?Ý0?Ù1 0 +0 *?H?÷
?Z0?s0?Ü !Cl6²V³h?pú0
*?H?÷
0ê1'0%U
The University of Texas System1 0 U VeriSign Trust Network1;09U 2Terms of use at https://www.verisign.com/rpa (c)991200U )Class 2 CA - OnSite Individual Subscriber1-0+U$The University of Texas at Dallas CA0
050810000000Z
060810235959Z0ô1'0%U
The University of Texas System1-0+U $The University of Texas at Dallas CA1F0DU =www.verisign.com/repository/CPS Incorp. by Ref.,LIAB.LTD(c)9910U Mail Stop - UTD10UPaul Schmehl1!0 *?H?÷
pauls (at) utdallas (dot) edu0 [email concealed]?0
*?H?÷
0?Ä¡æ?9"S,/èâD¸'ɺLsÚXï3a»
?ÂÀ?+±ga,Ó?P$ñX^ù$ã?¡X?'ÈlÖ ?úVç^ÚÅ?ÆÅïPN²3Jyfy(ÅK®ûRTØ????P&8 ½z
¥Æ«¸??=ùÃu[§Þî?X®}ìS)$-|ö I£?0?0 U 00 U 0pauls (at) utdallas (dot) edu0 [email concealed]?$U ?0?0? `?H?øE0?0++ https://www.verisign.com/rpa-
kr0Ò+0ÅÂNOTICE: Private key may be recovered by VeriSign's customer who may be able to decrypt messages you send to certificate holder. Use is subject to terms at https://www.verisign.com/rpa-kr (c)99.0 `?H?øB?0uU n0l0j h f?dhttp://onsitecrl.verisign.com/TheUnive
rsityofTexasSystemTheUniversityofTexasatDallasCA/LatestCRL.crl0 U
?0 U %0++0
*?H?÷
AØ: ³+Æü6?'â*Q?
VËD "??mÂrJ´
_û$P?o:¼LP?È*$ªøÉUÄ¿f? É´ïÕ?±ýºçY2ÝB6óÁ×ÎNøßÜÛ¾i?̶f:Ü
Ó?¡×ö÷S??ìÅa1ÌÑB{S~?q¡hUN©?l0?Ø0?A Aì =§?ÄöÕÝÑe0
*?H?÷
0Á1 0 UUS10U
VeriSign, Inc.1<0:U 3Class 2 Public Primary Certification Authority - G21:08U 1(c) 1998 VeriSign, Inc. - For authorized use only1 0 U VeriSign Trust Network0
990331000000Z
090330235959Z0ê1'0%U
The University of Texas System1 0 U VeriSign Trust Network1;09U 2Terms of use at https://www.verisign.com/rpa (c)991200U )Class 2 CA - OnSite Individual Subscriber1-0+U$The University of Texas at Dallas CA0?0
*?H?÷
0?¿êï?ë
Áù"ÁÑÁÌÛzÚ¾6Òp`0`åàS/5ôɨ)ÖÞ=ó?d}¾Ñ?Tx?ÿ¢xñû?«Ãü?LÂIA
áÀÒ¥×ü~ÿBQNtóÕhs¥]1øæ)%c¨#?Dj?°9ñïÛFXú¸ÏKózÁ¢I??#Cº?2?£¥0¢0
)U "0 ¤ 0 10UPrivateLabel1-1400 `?H?øB0DU =0;09 `?H?øE0*0(+ https://www.verisign.com/RPA0U
0ÿ0 U 0
*?H?÷
S µÜ²¶?Ñ P?É8yÜȲI¿¸S?o?̲äz|ü£è_a^_??ZÒ?"ñ¼íñT¶T¦T¡T¼iÇ!7¢?9?§¬ ?è?]?
H9Y?$ C¼??Ü?táæã¾j¤?11#%?¯º,Q?Y¦£?Ò´ÎT 0?0?l¹/`Ì??¡zF ¸[pl?¯0
*?H?÷
0Á1 0 UUS10U
VeriSign, Inc.1<0:U 3Class 2 Public Primary Certification Authority - G21:08U 1(c) 1998 VeriSign, Inc. - For authorized use only1 0 U VeriSign Trust Network0
980518000000Z
280801235959Z0Á1 0 UUS10U
VeriSign, Inc.1<0:U 3Class 2 Public Primary Certification Authority - G21:08U 1(c) 1998 VeriSign, Inc. - For authorized use only1 0 U VeriSign Trust Network0?0
*?H?÷
0?§?!t,çð?á?<!ñ?Û?é?ü¾_RÈÌ ,V,¸i,Ì? °?®yò9Á{?º
,èÂ?,ªié ôÇ©¤BÂ#OJØð¢û1lÉæo?'õæôLx?mëF?ú¹?ÉTò²Ä¯ÔF ZÉ0ÿ
lõ-mÎw0
*?H?÷
r.ùÑñqûÄ?öÅ^Q?@?¸hø? ?Øâ½ÿí¡æfê/ ôÊ×ê¥+?ö$`?MD.?¥Ä- Ó®xiorÚl®ðc?7æ»Ä0wÌI5ªÏØѾ·?GsjT"4d-¶?Y[´QY:³
ôßg ô2d^±Fr'?{ÅD´®1?Z0?V0ÿ0ê1'0%U
The University of Texas System1 0 U VeriSign Trust Network1;09U 2Terms of use at https://www.verisign.com/rpa (c)991200U )Class 2 CA - OnSite Individual Subscriber1-0+U$The University of Texas at Dallas CA!Cl6²V³h?pú0 + ±0 *?H?÷
1 *?H?÷
0 *?H?÷
1
060607010518Z0# *?H?÷
1qà??£D×aóúér[ïf½N0R *?H?÷
1E0C0
*?H?÷
0*?H?÷
?0
*?H?÷
@0+0
*?H?÷
(0
*?H?÷
??(C
eøÀ=ÕòÛ´ÙSËD(BB69~_]'b!Ä`}?µ?Nô À¾Î±{zÉ#r'?+q:×îC?ã?e»£°°?; qÂË©
v?u´Ý9µåð¥ìsiá?5´¶¦Z?1 b?¼[ÍYC30.Ùú0#?äÓ1ÿê
[ reply ]