Nabble - squirrelmail-devel

Re: Image extension issue in mime.php

2008-09-03T02:00:11Z

>>>>>> - IE interprets JavaScript when served within an "image" (that
>>>>>> is, something linked from <img src="">. - Apparently (?) it
>>>>>> doesn't do this when the file has a regular image extension, it
>>>>>> then processes it as an image. A typical Windows way of working
>>>>>> I guess.
>>>>>
>>>>> Hmm. Can anyone confirm this? Are there any sample URIs that we
>>>>> can see for this?
>>>>>
>>>>> I tried this in IE6:
>>>>>
>>>>> <img src='javascript:alert("hello")' />
>>>>
>>>> The linked image file should contain the JavaScript. E.g.:
>>>> <img src='http://example.com/example.html' />
>>>> and then example.html contains javascript instead of an image. IE
>>>> will allegedly interpret the javascript in the file even though it
>>>> has no business doing that as it is an image.
>>>
>>> I see. IE interprets any JavaScript loaded in a remote file unless
>>> the extension is .png, .gif, etc....? That's a bit much, now, isn't
>>> it?
>>
>> The only thing I can find is this:
>>
>> http://ha.ckers.org/blog/20070623/hiding-js-in-valid-images/
>>
>> but it's limited to the src attribute in a script tag. I created some
>> "hacked" gif files with JavaScript in them and IE 6 (I think this
>> might be fixed in IE 7 too) only executes the JavaScript when it's
>> included in a script tag. When you put that into an email, SM sanitizes
>> the script tag before the code in question here ever sees it.
>>
>>> If this is what we are fighting, then the extension list by
>>> definition of the way IE works seems like the ONLY way to prevent the
>>> problem, that is unless we were to pre-fetch the content and scan it
>>> ourselves and judge if the content was really an image file or not.
>>
>> So, although I'm still not convinced that there should be any
>> restriction here at all, I created some code that does just this - it
>> keeps the file extension check since that's not resource intensive, but
>> if that test fails, it tries to fetch the resource (fopen, fread) and
>> then run the content through mime_content_type() to detect the content
>> type. The file is only then blocked if not an image file.
>>
>> Patch is attached (for STABLE, but should be the same or very similar
>> for DEVEL), but again, I'm not sure we need to make any restrictions here
>> whatsoever -- ??
>
> Anyone have any feedback on this? If no one does, what I'm thinking
> I'll do is commit this patch, BUT comment it out. So some code will
> be there to use if a vulnerability is found, but for now, the
> functionality will be to allow all image src URIs, since I can't find any
> evidence that it can be exploited.

I don't have an opinion about this. Do what you feel is best.

Sincerely,
Fredrik

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Image extension issue in mime.php

2008-09-02T18:43:49Z

Barbara,

You should not be subscribed to this mailing list. This list is for
SquirrelMail *software developers* only. You apparently have an issue
with *using* the SquirrelMail software. You should contact your
service provider and ask them to install the "HTML Mail" plugin.
Please don't reply on this mailing list. See:

http://squirrelmail.org/support/enduser.php

Good luck,

Paul

On Tue, Sep 2, 2008 at 6:12 PM, <BarbaraInMemphis@...> wrote:

> Hi Paul,
> I don't think this was supposed to come to me. I have NO idea what you are
> talking about -- lol. I did submit a question asking about the ability to
> change the font when writing an email. My host is LunarPages & I use
> SquirrelMail.
> Barbara
>
> In a message dated 9/2/2008 7:51:14 P.M. Central Daylight Time,
> paul@... writes:
>
> On Sun, Aug 24, 2008 at 12:23 AM, Paul Lesniewski <paul@...>
> wrote:
>>>>>> - IE interprets JavaScript when served within an "image" (that is,
>>>>>> something linked from <img src="">. - Apparently (?) it doesn't do
>>>>>> this
>>>>>> when the file has a regular image extension, it then processes it as
>>>>>> an
>>>>>> image. A typical Windows way of working I guess.
>>>>>>
>>>>>
>>>>> Hmm. Can anyone confirm this? Are there any sample URIs that we can
>>>>> see for this?
>>>>>
>>>>> I tried this in IE6:
>>>>>
>>>>> <img src='javascript:alert("hello")' />
>>>>
>>>> The linked image file should contain the JavaScript. E.g.:
>>>> <img src='http://example.com/example.html' />
>>>> and then example.html contains javascript instead of an image. IE will
>>>> allegedly interpret the javascript in the file even though it has no
>>>> business doing that as it is an image.
>>>
>>> I see. IE interprets any JavaScript loaded in a remote file unless
>>> the extension is .png, .gif, etc....? That's a bit much, now, isn't
>>> it?
>>
>> The only thing I can find is this:
>>
>> http://ha.ckers.org/blog/20070623/hiding-js-in-valid-images/
>>
>> but it's limited to the src attribute in a script tag. I created some
>> "hacked" gif files with JavaScript in them and IE 6 (I think this
>> might be fixed in IE 7 too) only executes the JavaScript when it's
>> included in a script tag. When you put that into an email, SM
>> sanitizes the script tag before the code in question here ever sees
>> it.
>>
>>> If this is what we are fighting, then the extension list by
>>> definition of the way IE works seems like the ONLY way to prevent the
>>> problem, that is unless we were to pre-fetch the content and scan it
>>> ourselves and judge if the content was really an image file or not.
>>
>> So, although I'm still not convinced that there should be any
>> restriction here at all, I created some code that does just this - it
>> keeps the file extension check since that's not resource intensive,
>> but if that test fails, it tries to fetch the resource (fopen, fread)
>> and then run the content through mime_content_type() to detect the
>> content type. The file is only then blocked if not an image file.
>>
>> Patch is attached (for STABLE, but should be the same or very similar
>> for DEVEL), but again, I'm not sure we need to make any restrictions
>> here whatsoever -- ??
>
> Anyone have any feedback on this? If no one does, what I'm thinking
> I'll do is commit this patch, BUT comment it out. So some code will
> be there to use if a vulnerability is found, but for now, the
> functionality will be to allow all image src URIs, since I can't find
> any evidence that it can be exploited.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> -----
> squirrelmail-devel mailing list
> Posting guidelines: http://squirrelmail.org/postingguidelines
> List address: squirrelmail-devel@...
> List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
> List info (subscribe/unsubscribe/change options):
> https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
>
>
>
> ________________________________
> It's only a deal if it's where you want to go. Find your travel deal here.
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> -----
> squirrelmail-devel mailing list
> Posting guidelines: http://squirrelmail.org/postingguidelines
> List address: squirrelmail-devel@...
> List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
> List info (subscribe/unsubscribe/change options):
> https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
>

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Image extension issue in mime.php

2008-09-02T18:12:25Z

Hi Paul,

I don't think this was supposed to come to me. I have NO idea what you are talking about -- lol. I did submit a question asking about the ability to change the font when writing an email. My host is LunarPages & I use SquirrelMail.

Barbara

In a message dated 9/2/2008 7:51:14 P.M. Central Daylight Time, paul@... writes:

On Sun, Aug 24, 2008 at 12:23 AM, Paul Lesniewski <paul@...> wrote:

>>>>> - IE interprets JavaScript when served within an "image" (that is,
>>>>> something linked from <img src="">. - Apparently (?) it doesn't do this
>>>>> when the file has a regular image extension, it then processes it as an
>>>>> image. A typical Windows way of working I guess.
>>>>>
>>>>
>>>> Hmm. Can anyone confirm this? Are there any sample URIs that we can
>>>> see for this?
>>>>
>>>> I tried this in IE6:
>>>>
>>>> <img src='javascript:alert("hello")' />
>>>
>>> The linked image file should contain the JavaScript. E.g.:
>>> <img src='http://example.com/example.html' />
>>> and then example.html contains javascript instead of an image. IE will
>>> allegedly interpret the javascript in the file even though it has no
>>> business doing that as it is an image.
>>
>> I see. IE interprets any JavaScript loaded in a remote file unless
>> the extension is .png, .gif, etc....? That's a bit much, now, isn't
>> it?
>
> The only thing I can find is this:
>
> http://ha.ckers.org/blog/20070623/hiding-js-in-valid-images/
>
> but it's limited to the src attribute in a script tag. I created some
> "hacked" gif files with JavaScript in them and IE 6 (I think this
> might be fixed in IE 7 too) only executes the JavaScript when it's
> included in a script tag. When you put that into an email, SM
> sanitizes the script tag before the code in question here ever sees
> it.
>
>> If this is what we are fighting, then the extension list by
>> definition of the way IE works seems like the ONLY way to prevent the
>> problem, that is unless we were to pre-fetch the content and scan it
>> ourselves and judge if the content was really an image file or not.
>
> So, although I'm still not convinced that there should be any
> restriction here at all, I created some code that does just this - it
> keeps the file extension check since that's not resource intensive,
> but if that test fails, it tries to fetch the resource (fopen, fread)
> and then run the content through mime_content_type() to detect the
> content type. The file is only then blocked if not an image file.
>
> Patch is attached (for STABLE, but should be the same or very similar
> for DEVEL), but again, I'm not sure we need to make any restrictions
> here whatsoever -- ??

Anyone have any feedback on this? If no one does, what I'm thinking
I'll do is commit this patch, BUT comment it out. So some code will
be there to use if a vulnerability is found, but for now, the
functionality will be to allow all image src URIs, since I can't find
any evidence that it can be exploited.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

It's only a deal if it's where you want to go. Find your travel deal here.

Re: Image extension issue in mime.php

2008-09-02T17:50:45Z

On Sun, Aug 24, 2008 at 12:23 AM, Paul Lesniewski <paul@...> wrote:

>>>>> - IE interprets JavaScript when served within an "image" (that is,
>>>>> something linked from <img src="">. - Apparently (?) it doesn't do this
>>>>> when the file has a regular image extension, it then processes it as an
>>>>> image. A typical Windows way of working I guess.
>>>>>
>>>>
>>>> Hmm. Can anyone confirm this? Are there any sample URIs that we can
>>>> see for this?
>>>>
>>>> I tried this in IE6:
>>>>
>>>> <img src='javascript:alert("hello")' />
>>>
>>> The linked image file should contain the JavaScript. E.g.:
>>> <img src='http://example.com/example.html' />
>>> and then example.html contains javascript instead of an image. IE will
>>> allegedly interpret the javascript in the file even though it has no
>>> business doing that as it is an image.
>>
>> I see. IE interprets any JavaScript loaded in a remote file unless
>> the extension is .png, .gif, etc....? That's a bit much, now, isn't
>> it?
>
> The only thing I can find is this:
>
> http://ha.ckers.org/blog/20070623/hiding-js-in-valid-images/
>
> but it's limited to the src attribute in a script tag. I created some
> "hacked" gif files with JavaScript in them and IE 6 (I think this
> might be fixed in IE 7 too) only executes the JavaScript when it's
> included in a script tag. When you put that into an email, SM
> sanitizes the script tag before the code in question here ever sees
> it.
>
>> If this is what we are fighting, then the extension list by
>> definition of the way IE works seems like the ONLY way to prevent the
>> problem, that is unless we were to pre-fetch the content and scan it
>> ourselves and judge if the content was really an image file or not.
>
> So, although I'm still not convinced that there should be any
> restriction here at all, I created some code that does just this - it
> keeps the file extension check since that's not resource intensive,
> but if that test fails, it tries to fetch the resource (fopen, fread)
> and then run the content through mime_content_type() to detect the
> content type. The file is only then blocked if not an image file.
>
> Patch is attached (for STABLE, but should be the same or very similar
> for DEVEL), but again, I'm not sure we need to make any restrictions
> here whatsoever -- ??

Anyone have any feedback on this? If no one does, what I'm thinking
I'll do is commit this patch, BUT comment it out. So some code will
be there to use if a vulnerability is found, but for now, the
functionality will be to allow all image src URIs, since I can't find
any evidence that it can be exploited.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Image extension issue in mime.php

2008-08-24T00:23:21Z

>>>> - IE interprets JavaScript when served within an "image" (that is,

>>>> something linked from <img src="">. - Apparently (?) it doesn't do this
>>>> when the file has a regular image extension, it then processes it as an
>>>> image. A typical Windows way of working I guess.
>>>>
>>>
>>> Hmm. Can anyone confirm this? Are there any sample URIs that we can
>>> see for this?
>>>
>>> I tried this in IE6:
>>>
>>> <img src='javascript:alert("hello")' />
>>
>> The linked image file should contain the JavaScript. E.g.:
>> <img src='http://example.com/example.html' />
>> and then example.html contains javascript instead of an image. IE will
>> allegedly interpret the javascript in the file even though it has no
>> business doing that as it is an image.
>
> I see. IE interprets any JavaScript loaded in a remote file unless
> the extension is .png, .gif, etc....? That's a bit much, now, isn't
> it?

The only thing I can find is this:

http://ha.ckers.org/blog/20070623/hiding-js-in-valid-images/

but it's limited to the src attribute in a script tag. I created some
"hacked" gif files with JavaScript in them and IE 6 (I think this
might be fixed in IE 7 too) only executes the JavaScript when it's
included in a script tag. When you put that into an email, SM
sanitizes the script tag before the code in question here ever sees
it.

> If this is what we are fighting, then the extension list by
> definition of the way IE works seems like the ONLY way to prevent the
> problem, that is unless we were to pre-fetch the content and scan it
> ourselves and judge if the content was really an image file or not.

So, although I'm still not convinced that there should be any
restriction here at all, I created some code that does just this - it
keeps the file extension check since that's not resource intensive,
but if that test fails, it tries to fetch the resource (fopen, fread)
and then run the content through mime_content_type() to detect the
content type. The file is only then blocked if not an image file.

Patch is attached (for STABLE, but should be the same or very similar
for DEVEL), but again, I'm not sure we need to make any restrictions
here whatsoever -- ??

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

check_image_content.diff (5K) Download Attachment

Re: Image extension issue in mime.php

2008-08-22T12:32:59Z

On Fri, Aug 22, 2008 at 2:13 AM, Thijs Kinkhorst <kink@...> wrote:

> On Fri, August 22, 2008 10:03, Paul Lesniewski wrote:
>>> - IE interprets JavaScript when served within an "image" (that is,
>>> something linked from <img src="">. - Apparently (?) it doesn't do this
>>> when the file has a regular image extension, it then processes it as an
>>> image. A typical Windows way of working I guess.
>>>
>>
>> Hmm. Can anyone confirm this? Are there any sample URIs that we can
>> see for this?
>>
>> I tried this in IE6:
>>
>>
>> <img src='javascript:alert("hello")' />
>
> The linked image file should contain the JavaScript. E.g.:
> <img src='http://example.com/example.html' />
> and then example.html contains javascript instead of an image. IE will
> allegedly interpret the javascript in the file even though it has no
> business doing that as it is an image.

I see. IE interprets any JavaScript loaded in a remote file unless
the extension is .png, .gif, etc....? That's a bit much, now, isn't
it? If this is what we are fighting, then the extension list by
definition of the way IE works seems like the ONLY way to prevent the
problem, that is unless we were to pre-fetch the content and scan it
ourselves and judge if the content was really an image file or not.

There may be a PHP algorithm out there already written to do that, so
*maybe* that is possible, but short of that, it looks like we are
stuck: have some HTML mails with blanks where images should really be
shown or open IE users up to possible attacks via this mechanism.

I am going to run a test to try to reproduce the actual IE issue you
described, and I am going to look around to see if there is a way we
can do a pre-fetch and make a content judgment. Short of any other
ideas, though, it looks to me like the only thing we can do is let the
admin decide to open themselves up to this, or to build some 2nd level
of unsafe image viewing, where the user could click a *second* time to
show such images - but that may not be smart, since most users may not
understand the risk.

Oh, would it be safe to open SM up to any image URI as long as the
user agent is not IE?

Update - I just tried to use an image URI that loaded a php page that
serves this:

<script language="JavaScript" type="text/javascript">
alert("HELLO");
</script>

And in IE 6 it just gives a broken image (does NOT appear to interpret
the JavaScript!), as does FF.

Can anyone shed light on the actual vulnerability?

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Image extension issue in mime.php

2008-08-22T02:13:02Z

On Fri, August 22, 2008 10:03, Paul Lesniewski wrote:

>> - IE interprets JavaScript when served within an "image" (that is,
>> something linked from <img src="">. - Apparently (?) it doesn't do this
>> when the file has a regular image extension, it then processes it as an
>> image. A typical Windows way of working I guess.
>>
>
> Hmm. Can anyone confirm this? Are there any sample URIs that we can
> see for this?
>
> I tried this in IE6:
>
>
> <img src='javascript:alert("hello")' />

The linked image file should contain the JavaScript. E.g.:
<img src='http://example.com/example.html' />
and then example.html contains javascript instead of an image. IE will
allegedly interpret the javascript in the file even though it has no
business doing that as it is an image.

Something like that, all from the top of my head though.

Thijs

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Image extension issue in mime.php

2008-08-22T01:03:34Z

On Fri, Aug 22, 2008 at 12:44 AM, Thijs Kinkhorst <kink@...> wrote:

> On Friday 22 August 2008 09:17, Paul Lesniewski wrote:
>> It's your commit, so maybe you can help.
>>
>> http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4
>>-STABLE/squirrelmail/functions/mime.php?view=log#rev12370
>>
>> If this code is meant to stop "request forgeries through included
>> images", I'd like to know more about what this means, since, as I
>> noted, it wouldn't be hard for an attacker to substitute a dynamically
>> executed script for an "image" file on the target server. Or perhaps
>> the file extension code is not specifically what fixed that actual
>> issue and is only a side effect?
>
> The patch is actually by Marc. He had some discussion about it with Tomas that
> I could find. As far as I can distill from the mails, but it's a bit of
> guesswork:
>
> - IE interprets JavaScript when served within an "image" (that is, something
> linked from <img src="">.
> - Apparently (?) it doesn't do this when the file has a regular image
> extension, it then processes it as an image. A typical Windows way of working
> I guess.

Hmm. Can anyone confirm this? Are there any sample URIs that we can
see for this?

I tried this in IE6:

<img src='javascript:alert("hello")' />

Even when viewing unsafe images (and the file extension list
disabled), this is replaced with the "This image has been removed for
security reasons" image replacement, presumably because the text
"javascript" is found and removed. So, is the actual fix for the
javascript issue fixed elsewhere and the image file extension list
only intended to avoid showing the "image has been removed" thing when
the user does not expect it (because they already clicked to view
unsafe images)?

Or is there some other URI type that is the real problem here?

I'm still not convinced that the list can't be removed, but am hoping
anyone with more details or knowledge about the issue can voice their
opinion.

> I'm not sure that that is what it's supposed to fix as the mails aren't too
> clear on that. I also don't use IE so can't easily verify this theory.
>
> You could argue that pressing View Unsafe Images leaves you on your own which
> is sort of true, however, my perception of the function was to prevent remote
> tracking, and enabling it would not directly open you up to xss.

My thoughts exactly.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Image extension issue in mime.php

2008-08-22T00:44:30Z

On Friday 22 August 2008 09:17, Paul Lesniewski wrote:

> It's your commit, so maybe you can help.
>
> http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4
>-STABLE/squirrelmail/functions/mime.php?view=log#rev12370
>
> If this code is meant to stop "request forgeries through included
> images", I'd like to know more about what this means, since, as I
> noted, it wouldn't be hard for an attacker to substitute a dynamically
> executed script for an "image" file on the target server. Or perhaps
> the file extension code is not specifically what fixed that actual
> issue and is only a side effect?

The patch is actually by Marc. He had some discussion about it with Tomas that
I could find. As far as I can distill from the mails, but it's a bit of
guesswork:

- IE interprets JavaScript when served within an "image" (that is, something
linked from <img src="">.
- Apparently (?) it doesn't do this when the file has a regular image
extension, it then processes it as an image. A typical Windows way of working
I guess.

I'm not sure that that is what it's supposed to fix as the mails aren't too
clear on that. I also don't use IE so can't easily verify this theory.

You could argue that pressing View Unsafe Images leaves you on your own which
is sort of true, however, my perception of the function was to prevent remote
tracking, and enabling it would not directly open you up to xss.

cheers,
Thijs

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Image extension issue in mime.php

2008-08-22T00:31:55Z

On Fri, Aug 22, 2008 at 12:17 AM, Paul Lesniewski <paul@...> wrote:

> On Thu, Aug 21, 2008 at 2:58 AM, Thijs Kinkhorst <kink@...> wrote:
>> On Thu, August 21, 2008 03:30, Paul Lesniewski wrote:
>>> My feeling is that this should be addressed by either removing the
>>> restriction list completely,
>>
>> I would say "yes" to this, but would be curious where the original idea
>> comes from. Isn't that tracable in the commit log?
>
> It's your commit, so maybe you can help.
>
> http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/functions/mime.php?view=log#rev12370
>
> If this code is meant to stop "request forgeries through included
> images", I'd like to know more about what this means, since, as I
> noted, it wouldn't be hard for an attacker to substitute a dynamically
> executed script for an "image" file on the target server. Or perhaps
> the file extension code is not specifically what fixed that actual
> issue and is only a side effect?
>
> So if the extension limitation on image files is removed, does this
> expose SM to some XSS or something that it's not already exposed to
> now?

According to:

http://www.squirrelmail.org/security/issue/2007-05-09

'Request forgery through images. It was possible to include "images"
in HTML mails which were in fact GET requests for the compose.php page
sending mail. These images are now properly detected, and the compose
form will only send mail through a POST request.'

If this is the issue, then the fact that src/compose.php only accepts
the "send" variable submission *only* in POSTs, then the image
extension restriction is not necessary that I can see.

Can someone tell me what I might be missing? Otherwise, I am going to
look at removing that restriction list.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Image extension issue in mime.php

2008-08-22T00:17:08Z

On Thu, Aug 21, 2008 at 2:58 AM, Thijs Kinkhorst <kink@...> wrote:
> On Thu, August 21, 2008 03:30, Paul Lesniewski wrote:
>> My feeling is that this should be addressed by either removing the
>> restriction list completely,
>
> I would say "yes" to this, but would be curious where the original idea
> comes from. Isn't that tracable in the commit log?

It's your commit, so maybe you can help.

http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/branches/SM-1_4-STABLE/squirrelmail/functions/mime.php?view=log#rev12370

If this code is meant to stop "request forgeries through included
images", I'd like to know more about what this means, since, as I
noted, it wouldn't be hard for an attacker to substitute a dynamically
executed script for an "image" file on the target server. Or perhaps
the file extension code is not specifically what fixed that actual
issue and is only a side effect?

So if the extension limitation on image files is removed, does this
expose SM to some XSS or something that it's not already exposed to
now?

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: reviewing random seeding

2008-08-21T04:27:45Z

On Thu, August 21, 2008 13:18, Paul Lesniewski wrote:
> OTOH, as long as admins know it is weak, then we've done our part, and
> having the weak algorithm does discourage amateur hackers. What about
> replacing with a known better algorithm? Isn't there somewhere we are
> using something better?

The problem is dat the encrypted password is stored in someone's pref file
and there's no real way to store that individual's encryption key other
than also in pref files or things similarly readable for those reading the
pref files.

As said defence against such amateur hackers that they can't decrypt
something given the ciphertext, key and algorithm is not useful and only
distracts from the fact that the store is actually unprotected.

>> 2) php_combined_lcg() in global.php seeds the random number generator
>> in a not so secure fashion.
>>
>> I believe we should just rip out this seeding and replace it with a
>> call to sq_mt_randomize() instead so we have this code only in one
>> place.
>
> Sure, seems OK. It was probably put there because that section is a
> direct rip (apparently) from Gallery.

Ok.

Thijs

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: reviewing random seeding

2008-08-21T04:18:07Z

On Thu, Aug 21, 2008 at 3:12 AM, Thijs Kinkhorst <kink@...> wrote:

> Hey all,
>
> I've reviewed the seeding of the random number generator we do within
> SquirrelMail and have found the following points:
>
> 1) The mail_fetch function uses not so secure seeding of srand().
>
> However, the encryption used there is advertised as insecure anyway. I
> wonder whether we should not just remove that feature altogether.
> Trivially cracked encryption can be worse than no encryption because the
> effect is the same for an attacker but it may create some sense of
> security. What value does the function add if it's trivially cracked?

OTOH, as long as admins know it is weak, then we've done our part, and
having the weak algorithm does discourage amateur hackers. What about
replacing with a known better algorithm? Isn't there somewhere we are
using something better?

> 2) php_combined_lcg() in global.php seeds the random number generator in a
> not so secure fashion.
>
> I believe we should just rip out this seeding and replace it with a call
> to sq_mt_randomize() instead so we have this code only in one place.

Sure, seems OK. It was probably put there because that section is a
direct rip (apparently) from Gallery.

> 3) The behaviour of sq_mt_randomize() itself needs to be reviewed.
>
> We currently re-seed it with several unpredictable values. We need to find
> out whether re-seeding it actually adds randomness or just 'resets' the
> thing so only the last one is useful.
>
> PHP doesn't require seeding for versions 4.2 and up, but the PHP
> implementation is reportedly limited in randomness unfortunately. The
> newest suhosin patch is supposed to address that.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

reviewing random seeding

2008-08-21T03:12:12Z

Hey all,

I've reviewed the seeding of the random number generator we do within
SquirrelMail and have found the following points:

1) The mail_fetch function uses not so secure seeding of srand().

However, the encryption used there is advertised as insecure anyway. I
wonder whether we should not just remove that feature altogether.
Trivially cracked encryption can be worse than no encryption because the
effect is the same for an attacker but it may create some sense of
security. What value does the function add if it's trivially cracked?

2) php_combined_lcg() in global.php seeds the random number generator in a
not so secure fashion.

I believe we should just rip out this seeding and replace it with a call
to sq_mt_randomize() instead so we have this code only in one place.

3) The behaviour of sq_mt_randomize() itself needs to be reviewed.

We currently re-seed it with several unpredictable values. We need to find
out whether re-seeding it actually adds randomness or just 'resets' the
thing so only the last one is useful.

PHP doesn't require seeding for versions 4.2 and up, but the PHP
implementation is reportedly limited in randomness unfortunately. The
newest suhosin patch is supposed to address that.

cheers,
Thijs

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Image extension issue in mime.php

2008-08-21T02:58:06Z

On Thu, August 21, 2008 03:30, Paul Lesniewski wrote:
> My feeling is that this should be addressed by either removing the
> restriction list completely,

I would say "yes" to this, but would be curious where the original idea
comes from. Isn't that tracable in the commit log?

Thijs

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Image extension issue in mime.php

2008-08-20T18:30:26Z

All,

I was looking at an HTML email today that had an image URI that was
an .asp file. SM blocked it, even when I clicked to view unsafe
images.... and that's because of the .asp file extension. SM replaces
all images in HTML view with a blank image unless they are simple
image files with .jpg, .gif, .jpeg, .xjpeg, .jpe, .bmp, .png, or .xbm
extensions. In today's world, I think there are probably a lot of
images being served dynamically, with URIs that have PHP, JSP, ASP or
some other file extension. So, in a lot of cases, these should be
allowed and are not necessarily threatening or ill-intentioned.

Can someone explain the rationale of keeping the list more
restricted? What can a malicious image URI do if we open the list up
to such file extensions? Really, if an attacker wanted to do
something here, they could easily circumvent this restriction by
putting a URI with a "valid" (say .png) extension that was really a
php file that is dynamically executed on the target server. So what
does SM *GAIN* by keeping this list of known image extensions? (What
we *LOSE* is proper display of many valid HTML mails for our users.)

My feeling is that this should be addressed by either removing the
restriction list completely, adding .asp, .php, .jsp, and any other
common types, or putting a new configuration value in the config file
for admins who would like to do this themselves.

Thoughts please?

- Paul

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Updates in the plugin development documentation

2008-08-18T02:46:39Z

>> Commit 13252[1] introduced the following paragraphs:
>>
>> "A plugin can try to be smart about where to find the needed
>> configuration file by doing something such as this:
>>
>> if (!@include_once(SM_PATH . 'config/config_demo.php')) if
>> (!@include_once(SM_PATH . 'plugins/demo/config.php'))
>> @include_once(SM_PATH . 'plugins/demo/config.sample.php');
>>
>> This assumes that the plugin has some sensible defaults in the sample
>> configuration file - if the plugin must be configured specifically for
>> the system upon which it is installed, remove the third line in this
>> example."
>>
>> If a plugin has a general configuration that can make it work out of
>> the box in the most cases, I prefer to have that configuration coded
>> into the plugin itself.
>
> OK, then you should do that in your plugins. ;-) I think this has to
> be the choice of the author. For some plugins, it's just not sensible
> from a design or coding point of view to hard-code defaults. It makes
> more sense to me to use a default configuration file, which could be
> called config_default.php.
>
>> If a valid configuration file exists, the plugin will allow
>> this to overrule the pre-set configuration.
>
> Cascading configuration sets vs. just one should be the author's choice
> IMO.
>
>> I don't like to have the plugin read configuration from a configuration
>> file with the word "sample" in the filename, even if such a file
>> exists. One reason is that it encourages administrators to modify
>> "config.sample.php" instead of "config.php" which might cause them
>> trouble later.
>
> On one hand, they deserve it if they can't read the installation
> instructions. On the other hand, I understand the desire to make it easy
> to use for clueless admins too. Personally, at this juncture, I am not
> interested in going quite that far. What I can do, however, is use a
> config_default.php instead of config_sample.php. I will still include an
> example configuration file, though, named as you suggest below.
>
>> Another is that some distributions might want to have
>> "config.sample.php" in a documentation directory (and not a code
>> directory) when re-distributing.
>>
>> For these reasons I'd like to have the code and the describing text in
>> the documentation rewritten so that it doesn't suggest actual use of the
>> file "config.sample.php".
>>
>> And correct me if I'm wrong, but "sample" should really be "example",
>> since that's what's it all about. A "sample" is a small part of anything
>> or one of a number, intended to show the quality, style, or nature of
>> the whole. An "example" is a pattern or model, as of something to be
>> imitated or avoided. Could the documentation be updated with "sample"
>> replaced by "example", or is the old naming convention too much rooted?

I read through the changes in commit 13263[1]. Fair enough. Thanks.

Sincerely,
Fredrik

[1]
http://squirrelmail.svn.sourceforge.net/viewvc/squirrelmail/trunk/documentation/devel/devel.sgml?r1=13263&r2=13262&pathrev=13263

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Bug in digest_md5_parse_challenge

2008-08-16T21:31:59Z

On Sat, Aug 16, 2008 at 9:08 PM, Pablo Álvarez de Sotomayor Posadillo
<i02sopop@...> wrote:
> Paul> Additionally, if base64_decode() returns FALSE, we need to
> Paul> add one more line ABOVE the while statement so that the
> Paul> return value is initialized (otherwise, it should generate a
> Paul> PHP notice):
>
> Paul> $parsed = array();
>
> You are right once again, I'm just thinking about it. I attach the patch.

This is in our SVN now. Thanks again!

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Bug in digest_md5_parse_challenge

2008-08-16T21:08:01Z

Paul> Additionally, if base64_decode() returns FALSE, we need to
Paul> add one more line ABOVE the while statement so that the
Paul> return value is initialized (otherwise, it should generate a
Paul> PHP notice):

Paul> $parsed = array();

You are right once again, I'm just thinking about it. I attach the patch.

Regards

--
Pablo Álvarez de Sotomayor Posadillo
Ingeniero Técnico en Informática de Sistemas
http://ritho.net
"De todas las cosas que he perdido la que
mas hecho de menos es mi cerebro"

===File ~/auth_digest_md5_warning.patch=====================
Index: functions/auth.php
===================================================================
--- functions/auth.php (revision 13262)
+++ functions/auth.php (working copy)
@@ -199,7 +199,8 @@
*/
function digest_md5_parse_challenge($challenge) {
$challenge=base64_decode($challenge);
- while (isset($challenge) && $challenge !== FALSE) {
+ $parsed = array();
+ while (!empty($challenge)) {
if ($challenge{0} == ',') { // First char is a comma, must not be 1st time through loop
$challenge=substr($challenge,1);
}
============================================================

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Bug in digest_md5_parse_challenge

2008-08-16T21:01:38Z

Paul> The reason I chose !== was because with stable code, we need
Paul> to treat the rest of the code as a black box and touch as
Paul> little as we can with any changes, and the !== means it will
Paul> only test for a single condition (the one initially
Paul> identified, where base64_decode() returns specifically
Paul> FALSE), whereas != can catch any other value that can be
Paul> evaluated as FALSE such as 0, "", array(), and "0". It is
Paul> not good to make assumptions about the meaning of those
Paul> other possible values.

Paul> So, if we continue on that track, we'd have to add another
Paul> type-specific check, but I'm now going to step away from the
Paul> black box approach and look inside the loop, where we can
Paul> see that it is clear that any of the other types that can be
Paul> cast as boolean FALSE are not expected therein. Therefore,
Paul> the better solution is (and please, if you don't mind, test
Paul> this and let us know if it works OK):

Paul> while (!empty($challenge)) {

Yes, it's work ok. I'm agree with you in the reasoning, and clearly the
best solution is that.

Regards

--
Pablo Álvarez de Sotomayor Posadillo
Ingeniero Técnico en Informática de Sistemas
http://ritho.net
"De todas las cosas que he perdido la que
mas hecho de menos es mi cerebro"

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Bug in digest_md5_parse_challenge

2008-08-16T20:45:31Z

On Sat, Aug 16, 2008 at 8:42 PM, Paul Lesniewski <paul@...> wrote:

> On Sat, Aug 16, 2008 at 8:38 PM, Paul Lesniewski <paul@...> wrote:
>> On Sat, Aug 16, 2008 at 8:00 PM, Pablo Álvarez de Sotomayor Posadillo
>> <i02sopop@...> wrote:
>>>
>>> Paul> If base64_decode() returns FALSE, then !== should catch it.
>>> Paul> Can you explain why !== does not work?
>>>
>>> Well, you are right, that solve the bug, but it still remain another
>>> bug, and I discovered it now, when I've check why with the !=
>>> condition turn off the warnings and with !== still remain. The new bug
>>> is produced because the while loops once more than the neccesary, that
>>> is, in each while loop the function substract one part of the
>>> $challenge string, so when the string is empty it shows a message
>>> warning about that (the exact message is " Uninitialized string
>>> offset: 0"). The program pass the !== condition if the variables are
>>> not equals or not of the same type, so, in the case described, a
>>> boolean type is diferent from a string type, passing the condition. In
>>> the other hand, with the != condition your are doing an underlying
>>> cast and the while stops at the correct loop. Remember that an empty
>>> string ("") is considered as FALSE in a cast conversion. So, finally,
>>> or you put one != condition or you put two !== condition (one with the
>>> boolean comparision and another one with the string comparision), but
>>> in the first case it's recommended a comment explaining that
>>> comparision.
>>
>> The reason I chose !== was because with stable code, we need to treat
>> the rest of the code as a black box and touch as little as we can with
>> any changes, and the !== means it will only test for a single
>> condition (the one initially identified, where base64_decode() returns
>> specifically FALSE), whereas != can catch any other value that can be
>> evaluated as FALSE such as 0, "", array(), and "0". It is not good to
>> make assumptions about the meaning of those other possible values.
>>
>> So, if we continue on that track, we'd have to add another
>> type-specific check, but I'm now going to step away from the black box
>> approach and look inside the loop, where we can see that it is clear
>> that any of the other types that can be cast as boolean FALSE are not
>> expected therein. Therefore, the better solution is (and please, if
>> you don't mind, test this and let us know if it works OK):
>>
>> while (!empty($challenge)) {
>
> Additionally, if base64_decode() returns FALSE, we need to add one
> more line ABOVE the while statement so that the return value is
> initialized (otherwise, it should generate a PHP notice):
>
> $parsed = array();

Although that would also be expected to generate more notices in
digest_md5_response(), and although technically there should be some
more robust error checking here, I think the overall assumption is
that if you get that far, you have bigger problems (this functionality
not configured correctly on the server).

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Bug in digest_md5_parse_challenge

2008-08-16T20:42:57Z

On Sat, Aug 16, 2008 at 8:38 PM, Paul Lesniewski <paul@...> wrote:

> On Sat, Aug 16, 2008 at 8:00 PM, Pablo Álvarez de Sotomayor Posadillo
> <i02sopop@...> wrote:
>>
>> Paul> If base64_decode() returns FALSE, then !== should catch it.
>> Paul> Can you explain why !== does not work?
>>
>> Well, you are right, that solve the bug, but it still remain another
>> bug, and I discovered it now, when I've check why with the !=
>> condition turn off the warnings and with !== still remain. The new bug
>> is produced because the while loops once more than the neccesary, that
>> is, in each while loop the function substract one part of the
>> $challenge string, so when the string is empty it shows a message
>> warning about that (the exact message is " Uninitialized string
>> offset: 0"). The program pass the !== condition if the variables are
>> not equals or not of the same type, so, in the case described, a
>> boolean type is diferent from a string type, passing the condition. In
>> the other hand, with the != condition your are doing an underlying
>> cast and the while stops at the correct loop. Remember that an empty
>> string ("") is considered as FALSE in a cast conversion. So, finally,
>> or you put one != condition or you put two !== condition (one with the
>> boolean comparision and another one with the string comparision), but
>> in the first case it's recommended a comment explaining that
>> comparision.
>
> The reason I chose !== was because with stable code, we need to treat
> the rest of the code as a black box and touch as little as we can with
> any changes, and the !== means it will only test for a single
> condition (the one initially identified, where base64_decode() returns
> specifically FALSE), whereas != can catch any other value that can be
> evaluated as FALSE such as 0, "", array(), and "0". It is not good to
> make assumptions about the meaning of those other possible values.
>
> So, if we continue on that track, we'd have to add another
> type-specific check, but I'm now going to step away from the black box
> approach and look inside the loop, where we can see that it is clear
> that any of the other types that can be cast as boolean FALSE are not
> expected therein. Therefore, the better solution is (and please, if
> you don't mind, test this and let us know if it works OK):
>
> while (!empty($challenge)) {

Additionally, if base64_decode() returns FALSE, we need to add one
more line ABOVE the while statement so that the return value is
initialized (otherwise, it should generate a PHP notice):

$parsed = array();

Cheers,

Paul

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Bug in digest_md5_parse_challenge

2008-08-16T20:38:09Z

On Sat, Aug 16, 2008 at 8:00 PM, Pablo Álvarez de Sotomayor Posadillo
<i02sopop@...> wrote:

>
> Paul> If base64_decode() returns FALSE, then !== should catch it.
> Paul> Can you explain why !== does not work?
>
> Well, you are right, that solve the bug, but it still remain another
> bug, and I discovered it now, when I've check why with the !=
> condition turn off the warnings and with !== still remain. The new bug
> is produced because the while loops once more than the neccesary, that
> is, in each while loop the function substract one part of the
> $challenge string, so when the string is empty it shows a message
> warning about that (the exact message is " Uninitialized string
> offset: 0"). The program pass the !== condition if the variables are
> not equals or not of the same type, so, in the case described, a
> boolean type is diferent from a string type, passing the condition. In
> the other hand, with the != condition your are doing an underlying
> cast and the while stops at the correct loop. Remember that an empty
> string ("") is considered as FALSE in a cast conversion. So, finally,
> or you put one != condition or you put two !== condition (one with the
> boolean comparision and another one with the string comparision), but
> in the first case it's recommended a comment explaining that
> comparision.

The reason I chose !== was because with stable code, we need to treat
the rest of the code as a black box and touch as little as we can with
any changes, and the !== means it will only test for a single
condition (the one initially identified, where base64_decode() returns
specifically FALSE), whereas != can catch any other value that can be
evaluated as FALSE such as 0, "", array(), and "0". It is not good to
make assumptions about the meaning of those other possible values.

So, if we continue on that track, we'd have to add another
type-specific check, but I'm now going to step away from the black box
approach and look inside the loop, where we can see that it is clear
that any of the other types that can be cast as boolean FALSE are not
expected therein. Therefore, the better solution is (and please, if
you don't mind, test this and let us know if it works OK):

while (!empty($challenge)) {

Thanks again for your help.

Cheers,

Paul

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel

Re: Bug in digest_md5_parse_challenge

2008-08-16T20:00:58Z

Paul> If base64_decode() returns FALSE, then !== should catch it.
Paul> Can you explain why !== does not work?

Well, you are right, that solve the bug, but it still remain another
bug, and I discovered it now, when I've check why with the !=
condition turn off the warnings and with !== still remain. The new bug
is produced because the while loops once more than the neccesary, that
is, in each while loop the function substract one part of the
$challenge string, so when the string is empty it shows a message
warning about that (the exact message is " Uninitialized string
offset: 0"). The program pass the !== condition if the variables are
not equals or not of the same type, so, in the case described, a
boolean type is diferent from a string type, passing the condition. In
the other hand, with the != condition your are doing an underlying
cast and the while stops at the correct loop. Remember that an empty
string ("") is considered as FALSE in a cast conversion. So, finally,
or you put one != condition or you put two !== condition (one with the
boolean comparision and another one with the string comparision), but
in the first case it's recommended a comment explaining that
comparision.

regards

--
Pablo Álvarez de Sotomayor Posadillo
Ingeniero Técnico en Informática de Sistemas
http://ritho.net
"De todas las cosas que he perdido la que
mas hecho de menos es mi cerebro"

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel