[12862] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Microsoft Security Bulletin (MS99-051) (fwd)

daemon@ATHENA.MIT.EDU (David LeBlanc)
Mon Dec 6 14:41:39 1999

Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id:  <3.0.3.32.19991204134236.0349c680@mail.mindspring.com>
Date:         Sat, 4 Dec 1999 13:42:36 -0800
Reply-To: David LeBlanc <dleblanc@MINDSPRING.COM>
From: David LeBlanc <dleblanc@MINDSPRING.COM>
X-To:         Kris Kennaway <kris@HUB.FREEBSD.ORG>, BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <Pine.BSF.4.21.9912012014310.52288-100000@hub.freebsd.org>

At 08:17 PM 12/1/99 -0800, Kris Kennaway wrote:
>On Tue, 30 Nov 1999, David LeBlanc wrote:
>
>> >Regardless of that, how does the patch stop malicious users from
>> >producing AT jobs that have valid signatures and putting them in place?

>> The signature is based on a unique certificate that is stored in the
>> private data, and only admins can access the certificate.  So your
>> requirement to use this method (post-fix) to become admin is to be admin.

>Replay attack? I read the patch description as saying that it stores a
>signature in the file containing the AT job, which is verified at
>execution time. If you can read the job file as another user, you may be
>able to resubmit the same job multiple times, if the signature doesn't
>include data which is instance-specific (e.g. the job ID).

Here's what I was told:

"The ACL on an At job file denies read access to non-admins.
This prevents non-admins from copying a signed At job into
another admin-owned file."

BTW, job ID wouldn't be sufficient - those numbers do get reused.

If anyone else sees a problem with the current way it works, send mail to
secure@microsoft.com and/or to me - I'll do my best to follow up.

Thanks for pointing this out - though it seems painfully obvious now, I
hadn't thought of it on my own.


David LeBlanc
dleblanc@mindspring.com

home help back first fref pref prev next nref lref last post