Skip Menu |
Queue is disabled
This queue is disabled and you may not create new tickets in it.
Report information
Id: 38806
Status: open
Priority: 0/
Queue: qpsmtpd

Owner: Nobody
Requestors: charlieb-qpsmtpd [at] budge.apana.org.au
Cc:
AdminCc:



Subject: Inadequate validation of authentication data
Date: Mon, 27 Mar 2006 14:31:26 -0500 (EST)
To: qpsmtpd-bugs [...] develooper.com
From: Charlie Brady <charlieb-qpsmtpd [...] budge.apana.org.au>
Qpsmtpd::Auth doesn't validate LOGIN/PLAIN auth strings before dispatching to plugins, which can in turn expose inadequate validation in plugins, possibly leading to false positive authentication. See http://contribs.org/bugzilla/show_bug.cgi?id=1138 for one such case. --- qpsmtpd-0.31.1/lib/Qpsmtpd/Auth.pm 2005-11-18 04:45:36.000000000 -0500 +++ mezzanine_patched_qpsmtpd-0.31.1/lib/Qpsmtpd/Auth.pm 2006-03-26 11:58:27.000000000 -0500 @@ -240,12 +240,21 @@ } ( $passHash, $user, $passClear ) = split /\x0/, decode_base64($prekey); - + unless ($user && $passClear) + { + $session->respond(504, "Invalid authentification string"); + return DECLINED; + } } elsif ($mechanism eq "login") { if ( $prekey ) { ($passHash, $user, $passClear) = split /\x0/, decode_base64($prekey); + unless ($user && $passClear) + { + $session->respond(504, "Invalid authentification string"); + return DECLINED; + } } else {
Applied, thanks! Committed in r633. John
Subject: Re: [perl #38806] [RESOLVED] Inadequate validation of authentication data
Date: Fri, 7 Apr 2006 17:34:53 -0400 (EDT)
To: John Peacock via RT <qpsmtpd-bugs-followup [...] develooper.com>
From: Charlie Brady <charlieb-qpsmtpd [...] budge.apana.org.au>
Download (untitled) / with headers
text/plain 366b
On Fri, 7 Apr 2006, John Peacock via RT wrote: Show quoted text
> According to our records, your request regarding > "Inadequate validation of authentication data" > has been resolved.
How has it been resolved? This is the first I've heard, before this "RESOLVED" message. Show quoted text
Not publicly visible. Shouldn't it be?
CC: John Peacock via RT <qpsmtpd-bugs-followup [...] develooper.com>
Subject: Re: [perl #38806] [RESOLVED] Inadequate validation of authenticationdata
Date: Thu, 13 Apr 2006 14:02:45 -0400
To: qpsmtpd [...] perl.org, Charlie Brady <charlieb-qpsmtpd [...] budge.apana.org.au>
From: John Peacock <jpeacock [...] rowman.com>
Download (untitled) / with headers
text/plain 966b
Charlie Brady wrote: Show quoted text
> > On Fri, 7 Apr 2006, John Peacock via RT wrote: >
>> According to our records, your request regarding >> "Inadequate validation of authentication data" >> has been resolved.
> > How has it been resolved? This is the first I've heard, before this > "RESOLVED" message.
I would have thought that you would have gotten the previous message from RT (which I thought was the correct "Requester gets this" and not the, to my mind, mostly useless "just add some random note to RT that no one will ever see without hunting it down"). Sorry... Show quoted text
> > > Not publicly visible. Shouldn't it be?
Yeah, I suppose so. Robert will have to 'Make it So!' The guest user only has rights to the Perl5 and Parrot queues. It may be that if you create and login with a perl.org account, you will have read-only access to the qpsmtpd queue (I don't have enough rights in RT to check). John
CC: qpsmtpd [...] perl.org, Charlie Brady <charlieb-qpsmtpd [...] budge.apana.org.au>, John Peacock via RT <qpsmtpd-bugs-followup [...] develooper.com>
Subject: [OT] Comments in RT and RT for bug tracking (was Re: [perl #38806] [RESOLVED] Inadequate validation of authenticationdata)
Date: Fri, 14 Apr 2006 10:10:01 +1000
To: John Peacock <jpeacock [...] rowman.com>
From: Gordon Rowell <gordonr [...] gormand.com.au>
Download (untitled) / with headers
text/plain 1.6k
John Peacock wrote: Show quoted text
> I would have thought that you would have gotten the previous message from RT > (which I thought was the correct "Requester gets this" and not the, to my mind, > mostly useless "just add some random note to RT that no one will ever see > without hunting it down"). Sorry...
It may not be useful in this scenario, but it is very useful when using RT for customer support requests. The support team can comment on requests without them going to the requestor. A "proper" response can be sent to the requestor when the support team has decided such a response is ready to be sent. Obviously you need to be careful to use the correct address, but it's a lot better than the typical support scenario: - Ticket raised - Discussion in email between the support staff - Sanitised response to requestor - Dig through mailboxes to work out how to actually resolve the problem - Find that the person who knows is on holidays - ... With RT the internal and sanitised views can be kept in the same place. Part of the issue is that (IMO) RT is not the correct tool for development bug tracking. Issue tracking and development bug tracking are different beasts with quite different lifecycles. That's why I use RT for customer support and Bugzilla for development. The customer support world is about getting the customer issue resolved as quickly as reasonable, whether that is through a workaround, patch or hand-holding. The development world is about ensuring that the problem gets fixed in the longer term. The two worlds need to align for long term survival, but they have different expectations and timeframes. Thanks, Gordon
CC: qpsmtpd [...] perl.org, Charlie Brady <charlieb-qpsmtpd [...] budge.apana.org.au>, John Peacock via RT <qpsmtpd-bugs-followup [...] develooper.com>
Subject: Re: [OT] Comments in RT and RT for bug tracking (was Re: [perl #38806] [RESOLVED] Inadequate validation of authenticationdata)
Date: Fri, 14 Apr 2006 15:19:23 -0400
To: Gordon Rowell <gordonr [...] gormand.com.au>
From: John Peacock <jpeacock [...] rowman.com>
Download (untitled) / with headers
text/plain 1.5k
Gordon Rowell wrote: Show quoted text
> It may not be useful in this scenario, but it is very useful when using > RT for customer support requests. The support team can comment on > requests without them going to the requestor. A "proper" response can be > sent to the requestor when the support team has decided such a response > is ready to be sent.
I should have been more precise. Everything you say is true. The annoying thing to me is that the *default* value is "correspondence" and not "comment to requester" as I find the latter much more likely to be the correct choice. In the initial phase of any helpdesk request, there is likely to be at least a few rounds of trying to figure out what the user meant (not in this case). Only when sufficient information has been gained to start working the problem is there likely to be a need for internal communications. We use a commercial helpdesk package in-house (HelpStar) which has several ways to partition the ticket. The nice thing about it is that the "reply to sender" choice is sticky; once you are done diagnosing, you can flip that off and route the ticket to the correct person and the end user doesn't get confused by the messy details. This feature alone would make RT more useful in my estimation. I've been talking about running RT in-house for some of the "shared mailbox" accounts (sales queries, webmaster stuff). If I do, I may wind up ginning up some support for doing it that way... John -- John Peacock Director of Information Research and Technology Rowman & Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org