Bug#914632: uw-imap: CVE-2018-19518

2019-02-24 Thread Moritz Muehlenhoff
On Sun, Feb 24, 2019 at 02:53:41PM +0100, Magnus Holmgren wrote:
> Perhaps wanting to run imapd via remote shell is so rare that there's no need 
> to write a NEWS.Debian entry?

I agree, I don't think this needs a NEWS.Debian.

Cheers,
Moritz



Bug#914632: uw-imap: CVE-2018-19518

2019-02-24 Thread Thorsten Glaser
Hi Magnus,

>Perhaps wanting to run imapd via remote shell is so rare that there's
>no need to write a NEWS.Debian entry?

in case of doubt just write one, it does not hurt.

Are you going to upload within the next five days or so, or
do you need help? (We’re at a BSP and currently fixing stuff…)

Thanks,
//mirabilos
-- 
> Wish I had pine to hand :-( I'll give lynx a try, thanks.

Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine



Bug#914632: uw-imap: CVE-2018-19518

2019-02-24 Thread Magnus Holmgren
lördag 23 februari 2019 kl. 15:26:25 CET skrev  Salvatore Bonaccorso:
> On Sun, Jan 13, 2019 at 06:24:36PM +0100, Magnus Holmgren wrote:
> > söndag 13 januari 2019 kl. 08:31:28 CET skrev  Salvatore Bonaccorso:
> > > On Fri, Dec 28, 2018 at 10:22:53AM +0100, Moritz Mühlenhoff wrote:
> > > > On Wed, Dec 26, 2018 at 05:20:40PM +0100, Magnus Holmgren wrote:
> > > > > I'm wondering if anyone would complain if I'd disable RSH (SSH)
> > > > > connections
> > > > > altogether.
> > > > 
> > > > Full ack, that seems like the most sensible fix.
> > > 
> > > Any news on this approach, or did you spot any problem with that way?
> > 
> > Here's my plan. Removing the RSHPATH define should disable the insecure
> > code, I reckon. I just haven't been able to make gbp use my long PGP key
> > id...
> Any news on this?

I thought I'd write a NEWS.Debian entry about disabling RSH, but then I 
realised it wouldn't be disabled completely, only by default; code using the 
library can still set rshpath by calling tcp_parameters(SET_RSHPATH, path). 
But maybe that's just fine. I also haven't got around to actually verifying 
that the patch works as intended.

Perhaps wanting to run imapd via remote shell is so rare that there's no need 
to write a NEWS.Debian entry?

-- 
Magnus Holmgrenholmg...@debian.org
Debian Developer 

signature.asc
Description: This is a digitally signed message part.


Bug#914632: uw-imap: CVE-2018-19518

2019-02-23 Thread Thorsten Glaser
Hi Magnus,

>I reckon. I just haven't been able to make gbp use my long PGP key id...

any progress with that? Otherwise I’d be willing to NMU your patch.

Greetings from the BSP,
//mirabilos
-- 
21:12⎜ sogar bei opensolaris haben die von der community so
ziemlich jeden mist eingebaut │ man sollte unices nich so machen das
desktopuser zuviel intresse kriegen │ das macht die code base kaputt
21:13⎜ linux war früher auch mal besser :D



Bug#914632: uw-imap: CVE-2018-19518

2019-02-23 Thread Salvatore Bonaccorso
Hi,

On Sun, Jan 13, 2019 at 06:24:36PM +0100, Magnus Holmgren wrote:
> söndag 13 januari 2019 kl. 08:31:28 CET skrev  Salvatore Bonaccorso:
> > On Fri, Dec 28, 2018 at 10:22:53AM +0100, Moritz Mühlenhoff wrote:
> > > On Wed, Dec 26, 2018 at 05:20:40PM +0100, Magnus Holmgren wrote:
> > > > I'm wondering if anyone would complain if I'd disable RSH (SSH)
> > > > connections
> > > > altogether.
> > > 
> > > Full ack, that seems like the most sensible fix.
> > 
> > Any news on this approach, or did you spot any problem with that way?
> 
> Here's my plan. Removing the RSHPATH define should disable the insecure code, 
> I reckon. I just haven't been able to make gbp use my long PGP key id...

Any news on this?

Regards,
Salvatore



Bug#914632: uw-imap: CVE-2018-19518

2019-01-13 Thread Magnus Holmgren
söndag 13 januari 2019 kl. 08:31:28 CET skrev  Salvatore Bonaccorso:
> On Fri, Dec 28, 2018 at 10:22:53AM +0100, Moritz Mühlenhoff wrote:
> > On Wed, Dec 26, 2018 at 05:20:40PM +0100, Magnus Holmgren wrote:
> > > I'm wondering if anyone would complain if I'd disable RSH (SSH)
> > > connections
> > > altogether.
> > 
> > Full ack, that seems like the most sensible fix.
> 
> Any news on this approach, or did you spot any problem with that way?

Here's my plan. Removing the RSHPATH define should disable the insecure code, 
I reckon. I just haven't been able to make gbp use my long PGP key id...

-- 
Magnus Holmgrenholmg...@debian.org
Debian Developer --- a/src/osdep/unix/Makefile
+++ b/src/osdep/unix/Makefile
@@ -985,7 +985,7 @@ onceenv:
 	 -DMD5ENABLE=\"$(MD5PWD)\" -DMAILSPOOL=\"$(MAILSPOOL)\" \
 	 -DANONYMOUSHOME=\"$(MAILSPOOL)/anonymous\" \
 	 -DACTIVEFILE=\"$(ACTIVEFILE)\" -DNEWSSPOOL=\"$(NEWSSPOOL)\" \
-	 -DRSHPATH=\"$(RSHPATH)\" -DLOCKPGM=\"$(LOCKPGM)\" \
+	 -DLOCKPGM=\"$(LOCKPGM)\" \
 	 -DLOCKPGM1=\"$(LOCKPGM1)\" -DLOCKPGM2=\"$(LOCKPGM2)\" \
 	 -DLOCKPGM3=\"$(LOCKPGM3)\" > OSCFLAGS
 	echo $(BASELDFLAGS) $(EXTRALDFLAGS) > LDFLAGS


signature.asc
Description: This is a digitally signed message part.


Bug#914632: uw-imap: CVE-2018-19518

2019-01-12 Thread Salvatore Bonaccorso
Hi Magnus,

On Fri, Dec 28, 2018 at 10:22:53AM +0100, Moritz Mühlenhoff wrote:
> On Wed, Dec 26, 2018 at 05:20:40PM +0100, Magnus Holmgren wrote:
> > > CVE-2018-19518[0]:
> > > | University of Washington IMAP Toolkit 2007f on UNIX, as used in
> > > | imap_open() in PHP and other products, launches an rsh command (by
> > > | means of the imap_rimap function in c-client/imap4r1.c and the
> > > | tcp_aopen function in osdep/unix/tcp_unix.c) without preventing
> > > | argument injection, 
> > 
> > I'm wondering if anyone would complain if I'd disable RSH (SSH) connections 
> > altogether.
> 
> Full ack, that seems like the most sensible fix.

Any news on this approach, or did you spot any problem with that way?

Regards,
Salvatore



Bug#914632: uw-imap: CVE-2018-19518

2018-12-28 Thread Moritz Mühlenhoff
On Wed, Dec 26, 2018 at 05:20:40PM +0100, Magnus Holmgren wrote:
> > CVE-2018-19518[0]:
> > | University of Washington IMAP Toolkit 2007f on UNIX, as used in
> > | imap_open() in PHP and other products, launches an rsh command (by
> > | means of the imap_rimap function in c-client/imap4r1.c and the
> > | tcp_aopen function in osdep/unix/tcp_unix.c) without preventing
> > | argument injection, 
> 
> I'm wondering if anyone would complain if I'd disable RSH (SSH) connections 
> altogether.

Full ack, that seems like the most sensible fix.

Cheers,
Moritz



Bug#914632: uw-imap: CVE-2018-19518

2018-12-26 Thread Magnus Holmgren
> CVE-2018-19518[0]:
> | University of Washington IMAP Toolkit 2007f on UNIX, as used in
> | imap_open() in PHP and other products, launches an rsh command (by
> | means of the imap_rimap function in c-client/imap4r1.c and the
> | tcp_aopen function in osdep/unix/tcp_unix.c) without preventing
> | argument injection, 

I'm wondering if anyone would complain if I'd disable RSH (SSH) connections 
altogether.

-- 
Magnus Holmgren
Debian Developer



Bug#914632: uw-imap: CVE-2018-19518

2018-11-25 Thread Salvatore Bonaccorso
Source: uw-imap
Version: 8:2007f~dfsg-5
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for uw-imap.

CVE-2018-19518[0]:
| University of Washington IMAP Toolkit 2007f on UNIX, as used in
| imap_open() in PHP and other products, launches an rsh command (by
| means of the imap_rimap function in c-client/imap4r1.c and the
| tcp_aopen function in osdep/unix/tcp_unix.c) without preventing
| argument injection, which might allow remote attackers to execute
| arbitrary OS commands if the IMAP server name is untrusted input (e.g.,
| entered by a user of a web application) and if rsh has been replaced by
| a program with different argument semantics. For example, if rsh is a
| link to ssh (as seen on Debian and Ubuntu systems), then the attack can
| use an IMAP server name containing a "-oProxyCommand" argument.

This was originally filled for PHP (cf. #913775 and cloned bugs), but
the issue could possibly be fixed within osdep/unix/tcp_unix.c in the
IMAP Toolkit code. See the security-tracker page for further
references.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-19518
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19518

Regards,
Salvatore