On Fri, Mar 16, 2007 at 10:22:05PM -0400, Derek Martin wrote:
> On Fri, Mar 16, 2007 at 12:40:27AM +, Paul Walker wrote:
> > If you can modify someones personal files, the game's already over.
> Not so. At least not necessarily.
So!
> Say there's a (purely hypothetical) bug in Mutt which al
Derek Martin wrote:
> On Fri, Mar 16, 2007 at 12:40:27AM +, Paul Walker wrote:
>>> setting, and I also don't think that any person interested in security
>>> should run with garbage in $PATH. I would also guess that it's just as
>> That's fine, and I would agree, but the person you're dealing w
On Sat, 17 Mar 2007, David Laight wrote:
In which case wouldn't 177 be better?
Unless mutt creates directories too.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
On Sat, Mar 17, 2007 at 12:11:29PM +0100, Bárður Árantsson wrote:
> > If the attacker is merely able to upload an arbitrary file, this is by
> > far the best route to go. He'll have to make guesses about the best
> > place to put his trojans, but as I just pointed out, that isn't
> > necessarily h
On Sat, Mar 17, 2007 at 12:05:49AM -0400, Derek Martin wrote:
> [stuff about strict umask and in another thread about hard-coded
> paths]
>
in short, all this stuff is discussing securing the door of a blown-up
house. mutt is just one application. if umask (or the ~/ mode) or PATH
are not set sensi
On Sat, Mar 17, 2007 at 11:08:12AM +, Ian Collier wrote:
> > Say there's a (purely hypothetical) bug in Mutt which allows an
> > attacker to cause mutt to download an arbitrary file (perhaps actually
> > in an application frequently used to aid mutt in viewing mail and/or
> > attachments, e.g.
$LD_LIBRARY_PATH and $LD_PRELOAD? You know, these are global
configuration variable, what's in here should be here for a reason. It
offers many creative ways of shooting yourself in the foot, but it also
offers many useful way of solving real-life problems. If you're not
confident in what's in t
On Sat, Mar 17, 2007 at 02:50:33PM +0100, Oswald Buddenhagen wrote:
> On Sat, Mar 17, 2007 at 12:05:49AM -0400, Derek Martin wrote:
> > [stuff about strict umask and in another thread about hard-coded
> > paths]
> >
> in short, all this stuff is discussing securing the door of a blown-up
> house. m
Derek Martin wrote on 17 Mar 2007 05:05:49 +0100:
> How many people reading this thought of the core dump problem I just
> mentioned?
Well, if your operating system creates world-readable coredump, you
should report this as a security vulnerabilty, because it is indeed one
(see http://www.securi
Gaëtan LEURENT wrote on 14 Mar 2007 15:53:36 +0100:
> I found a security vulnerability in the APOP authentication. It is
> related to recent collision attacks by Wang and al. against MD5.
Does somebody care about this, are you all busy reinventing Unix's
$PATH?
By the way, what's the next step
On Sat, Mar 17, 2007 at 04:35:33PM +0100, Gaëtan LEURENT wrote:
> Well, if your operating system creates world-readable coredump, you
> should report this as a security vulnerabilty, because it is indeed one
> (see http://www.securityfocus.com/bid/5737/info for instance).
Indeed. And if the use
On Sat, Mar 17, 2007 at 11:47:42AM -0400, Derek Martin wrote:
> > Could it be that you too are somewhat ignorant in security matters?
>
> Not at all; you're making my point.
Or rather, I meant to say yes, I am... just significantly less so than
most of the rest of you, I do believe...
--
Dere
I continue to think that the umask patch should't have been taken
into mutt. However, at this point, the decision is really
Brendan's.
That said, I think there are several questions to consider here:
- E-Mail systems are typically set up to create inboxes with rather
paranoid security settings
Rocco Rutte <[EMAIL PROTECTED]> writes:
> APOP IMHO should never be considered a secure way of authentication,
> it's just more secure than sending plain passwords over the wire. But
> yes, since the RfC says the "timestamp" must be syntacially valid
> message-id and mutt doesn't check it, there's
14 matches
Mail list logo
