The following is a Security Bulletin from the Microsoft Product Security
Notification Service.
Please do not reply to this message, as it was sent from an unattended
mailbox.
Microsoft Security Bulletin (MS99-027)
-
Wanted to advise that we have released Microsoft Security Bulletin MS99-027,
which discusses a patch to eliminate a mail relaying vulnerability in
Exchange 5.5. It's available at
http://www.microsoft.com/security/bulletins/ms99-027.asp. Regards,
[EMAIL PROTECTED]
On Fri, 6 Aug 1999, Dave Dittrich wrote:
> > With good reason. In bridging mode with a Windows 9x/NT box, your network
> > neighborhood will show everyone else's PC that has any file/print sharing
> > enabled. So, it's trivially easy to connect to a non-passworded share.
>
> That depends on the
> With good reason. In bridging mode with a Windows 9x/NT box, your network
> neighborhood will show everyone else's PC that has any file/print sharing
> enabled. So, it's trivially easy to connect to a non-passworded share.
That depends on the DSL provider, I believe. On my USWest.net DSL
con
On Thu, 5 Aug 1999 14:09:09 -0700, Matt <[EMAIL PROTECTED]> said:
Matt> The following URL contains information about a firmware upgrade
Matt> for FlowPoint DSL routers that fixes a possible "security
Matt> compromise". FlowPoint has chosen not to release ANY
Matt> information whatsoever about th
On Thu, 5 Aug 1999, John Horn wrote:
>
> Hmmm, interesting. Nevertheless, such activity contravenes various federal
> statutes and/or possibly state statutes at either the point of origination
> and/or the destination (or both). I would suggest that anyone interested
> in accepting this offer con
Since nobody has pointed it out yet it has been said by various people, at
least one of them in print, (including Spafford, I think) that these
challenges are unlikely to attract the real experts, who can charge large
consulting fees. It simply makes no sense for these people to give their
service
you can also find them easly by running a http server version reply.
The incorporated web server inside M3 Webramp returns this as version reply
without the <>.
I was aware about this problem for some time and the problem is very
dangerous.
IF you have more then 1modem attach to it you can sim
Research Advances in Intrusion Detection (RAID 99)
The 2nd annual RAID workshop will attract researchers, educators,
policy makers and technologists from around the world to the Purdue
University campus, September 7-9. The workshop will feature
research presentations, panels, and discussion on
On Sun, Aug 01, 1999 at 01:10:06AM +0200, Nergal wrote:
> Now let's recall another Linux feature. Many OSes (including Linux)
> assign to ID field of an outgoing IP datagram consecutive, increasing
> numbers (we forget about fragmentation here; irrelevant in this case). That
> enables anyone
> So, the version of my patch for 2.0.34 didn't need to fix this any
> more. Of course, future updates of the patch I was making based on
> the latest one, and never bothered to check for this bug again.
>
> Now, after your post, I am looking at patch-2.0.35.gz:
>
> - return 0;
> + return
In some mail from Theo de Raadt, sie said:
>
> > Apart from the ability to exchange files between users with
> > /tmp, having private /tmp's for each uid using the system (with a non-
> > world writeable /tmp) has a lot of merit which I hope someone will someday
> > properly explore - i.e. there e
>> Possible long-term fixes we've theo-rized:
>
>A strange pun.
yes. :)
>> c) Make root automatically override user-set flags (possibly will
>> create other complications for user-land programs relying on root
>> passing over such files). This would be akin to Solaris 2.51 and 2.6's
>> ACLs.
>
Why don't we just allow root to override immutable files so long as they
were not set immutable by root? This would allow root to safely trojan
proof its binaries while eliminating any race conditions that would
exist if we had to chflag first before accessing.
Brett Lymn wrote:
>
> According to
> In some mail from Theo de Raadt, sie said:
> [...]
> > > a) Root should not use /tmp. Root is root and, as the proverbial
> > > 800-pound gorilla, can make temporary files wherever it pleases.
> > > FreeBSD, for example, seems to be doing a lot in /var/run, which is
> > > root-owned, and not wo
On Thu, 5 Aug 1999, Theo de Raadt wrote:
> > Mike Frantzen ([EMAIL PROTECTED]), Kevin Kadow
> > ([EMAIL PROTECTED]), and I were discussing the implications of the above
> > revision to vfs_syscalls.c and realized it must be that root does not
> > automatically override user-set flags -- root must
In some mail from Theo de Raadt, sie said:
[...]
> > a) Root should not use /tmp. Root is root and, as the proverbial
> > 800-pound gorilla, can make temporary files wherever it pleases.
> > FreeBSD, for example, seems to be doing a lot in /var/run, which is
> > root-owned, and not world-writable
It seem I am not able to re-produce the problem any more. So...
sorry and never mind. I'll go sit in the corner now.
-- Yan
On Mon, Aug 02, 1999 at 04:58:43PM -0700, "Jan B. Koum " wrote:
>
> Running tcp nmap scan against Foundry network gear make it go boom.
> What makes it more
Isaac To wrote:
> But yes, it is ugly. It might be better if any SGID program is also SUID
> nobody, and re-acquire real user privilege only when required. But still,
> it is ugly.
That is not a viable approach unless the binary (and all other binaries
owned by nobody) also is immutable. If th
Hi!
Sorry if somebody has noticed this before or is only a stupid remark, but
a few days ago I found that you can kill vlock (and similar programs that
lock all linux consoles) with the alt+sysrq+k key combination on LiNUX 2.2.X
and 2.3.X (if you enabled magic keys when you compiled the kern
This could be good.. But this could be bad. Running on a system with out
the shadow password suite, then this would work very easily,
running on a machine with a shadow password suite, it would atleast
require the shadow file to be group writeable to the GID you run
the program as. Which in most c
Aleph1, I don't know if this posting is really pertinent to the list but
considering the potential for serious penalties, I thought it might be
advisable to point this out.
Hmmm, interesting. Nevertheless, such activity contravenes various federal
statutes and/or possibly state statutes at either
> Adam Morrison wrote:
> > From the OpenBSD change logs:
>
> > revision 1.59
> > date: 1999/07/30 18:27:47; author: deraadt; state: Exp; lines: +20 -1
> > do not permit regular users to chflags/fchflags on chr or blk devices --
> > even if they happen to own them at the moment.
>
> Mike Frantze
The following URL contains information about a firmware upgrade for
FlowPoint DSL routers that fixes a possible "security compromise".
FlowPoint has chosen not to release ANY information whatsoever about the
vulnerability. I was curious if anyone had any more information
about this vulnerability t
As I recall, when SYN floods were first becoming a hot topic on
comp.protocols.tcpip, the general consensus was to implement Random Early
Drop rather than an LRU queue for incomplete connections for precisely this
reason. RED tends to drop malicious, rather than innocent, packets because
they mak
25 matches
Mail list logo
