from:"Nick Boyce"

RE: flashplugin-nonfree and latest Flash security updates

2016-08-03 Thread Nick Boyce

On Wed, 3 Aug 2016 22:53:28 +
Bart Martens  wrote:

> On Mon, Aug 01, 2016 at 08:25:01AM -0700, Darren S. wrote:
[...]
> > 'update-flashplugin-nonfree --status` shows a newer release
> > of the plugin upstream.
> > 
> > 
> > options :  --verbose --status --
> > temporary directory: /tmp/flashplugin-nonfree.65hpQUuxtV
> > importing public key ...
> > selected action = --status
> > Flash Player version installed on this system  : 11.2.202.626
> > Flash Player version available on upstream site: 22.0.0.209  
> 
> That is now 11.2.202.632. You may need to delete
> /var/cache/flashplugin-nonfree/get-upstream-version.pl and try again.

Thanks for sorting it out Bart.
FWIW, in my throwaway BBC-news-reading VM, which is still Debian
Wheezy, I did indeed have to delete that cached script, after which the
update worked perfectly and the Flash player is working normally.

Cheers
Nick
-- 
The two "sides" in the systemd debate are (a) the one that has 
cursory knowledge of the evolution of other operating systems 
over the past two decades, and (b) the side that's basically 
90's Linux-Amish.   ~~ Slashdot comment

RE: flashplugin-nonfree and latest Flash security updates

2016-08-03 Thread Nick Boyce

On Wed, 3 Aug 2016 20:47:45 +0200
Moritz Mühlenhoff <j...@inutil.org> wrote:

> Nick Boyce <n...@glimmer.demon.co.uk> schrieb:

> > assuming Bart is MIA for some reason, is it possible
> > for the Security Team to either fix the update, or to make an
> > announcement that all Debian users should stop using the Adobe
> > player immediately ?  
> 
> No, non-free/contrib is not supported by the security team.

Okay - thanks Moritz.

> Just don't use that crap. With the amount of zero days in Flash
> you're subject to serious vulnerabilities even with an up-to-date
> plugin.

Well you're right of course, though as I said in reply to Paul Wise
there is still a use-case with no alternative at the BBC News website,
and if a throwaway VM is used then the risk is mostly mitigated.  Also I
believe there are quite a few corporate intranet use-cases that *depend*
on Flash for corporate web-apps (at least according to traffic on the
Enterprise Firefox list).

Cheers,
Nick
-- 
In a world where Henry Kissinger wins the Nobel Peace Prize,
there is no need for satire.
- Tom Lehrer

RE: flashplugin-nonfree and latest Flash security updates

2016-08-03 Thread Nick Boyce

On Wed, 3 Aug 2016 17:55:43 +0800
Paul Wise <p...@debian.org> wrote:

> On Wed, Aug 3, 2016 at 8:29 AM, Nick Boyce wrote:
[snip] 
> > I realise the nonfree plugin is not really supported, but ...
> > assuming Bart is MIA for some reason, is it possible for the
> > Security Team to either fix the update, or to make an announcement
> > that all Debian users should stop using the Adobe player
> > immediately ?  
> 
> I'm not part of the team, but I do know that contrib and non-free are
> not supported by the Debian security team, so they are unlikely to
> make any fixes nor announcements.
> 
> https://www.debian.org/security/faq#contrib

Thanks. Link read, point taken (although the link does imply the
Security Team will sometimes make appropriate announcements about such
unsupported packages).

> I'd encourage everyone reading this list to use this opportunity
> transition away from using the Adobe Flash player. Most of the web
> should support standard HTML5 by now

I'd love to.  Actually I have removed Flash from almost all my systems
now because, as you say, most sites have introduced HTML5
replacements [*].  I have just one use-case left: for some reason the
BBC News website still requires Flash to show news video clips, although
all other BBC properties seem to have an HTML5 alternative, even if
still beta.  I have a throwaway Debian VM for that purpose, and would
like to use Flash in it for as long as the need remains.

[*] of course, some observers are wondering what new security hell may
be delivered along with HTML5 media players, but that's another
conversation about which I have no personal opinion :-)

Cheers,
Nick
-- 
The Unix man pages were written by Vogons. Drunk Vogons. 
Practicing poetry whilst smashing snails with hammers.
 ~~ Slashdot comment

RE: flashplugin-nonfree and latest Flash security updates

2016-08-02 Thread Nick Boyce

On Mon, 1 Aug 2016 08:25:01 -0700
Darren S.  wrote:

> There are aspects of the flashplugin-nonfree package I am hoping to
> understand better in respect to installing the latest security updates
> for the Adobe Flash plugin on a Debian host.
[snip]
> It appears that the updated Flash plugin version fails to be
> fetched/verified because of a 404 on the Debian server. This updated
> version doesn't appear to be the one that would work with Firefox on
> Linux anyway, as that would be 11.2.202.632. However when
> update-flashplugin-nonfree fetches and installs an 11.x version, it
> drops in the slightly older 11.2.202.626 version which is still
> considered vulnerable in the browser.
> 
> Is there a way for this to be corrected?

+1

The update-flashplugin-nonfree facility has been broken for several
days now.  It reports the upstream plugin version is 22.0.0.209, but
that is not true - the latest plugin version for Linux systems is
11.2.202.632, as shown at
https://www.adobe.com/products/flashplayer/distribution3.html

The 22.0.0.209 version is for Windows, Mac and potentially also
for Google Chrome on Linux.  IIRC, the Google Chrome version is the new
style PPAPI plugin, whereas Firefox/Iceweasel needs the older NPAPI
technology, so I have not actually run the update cos the last thing I
would want is a plugin which won't work at all.

I have emailed the maintainer (Bart Martens, at his debian.org address)
twice about this (30th.July and 1st.Aug), but there has been no reply as
yet. Do I need to post to the bug report Francesco mentioned:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820583
rather than emailing Bart directly ?

I realise the nonfree plugin is not really supported, but given the
serious (!!!) security implications of running a known-vulnerable Flash
player for a significant time after a fixed version has been released,
and assuming Bart is MIA for some reason, is it possible for the
Security Team to either fix the update, or to make an announcement that
all Debian users should stop using the Adobe player immediately ?

Thanks,
Nick
-- 
"Always code as if the person who ends up maintaining your code 
is a violent psychopath who knows where you live."
-- John Woods

Re: Please remove me from this list

2014-06-27 Thread Nick Boyce

On Wed, 25 Jun 2014 23:43:36 -0500
Scott Blaydes sblay...@netteksolutions.com wrote:

 Doesn’t it make you wonder about a company who’s Privacy, Security
 and Compliance Officer can’t figure out how to get off of a mailing
 list that he had to subscribe to and verify his address for?

Yep - it's both amusing and horrifying.  He's not just the 'Privacy,
Security and Compliance Officer', but also the 'Manager, Technology
Security and Compliance'.  One can only hope his attention to detail is
greater when he's managing security and technology.

 I know, I am a jerk, but it was the first thing I thought of

I don't think that makes you a jerk at all.  IMHO one of the most
serious deteriorations in our profession has been the rise of slapdash,
non-technical, shoot-from-the-hip people to positions of power and
control. Raising your eyebrows at this trend does not make you a jerk.
It might make you humourless, but I'm sure that just applies to me :)

Measure twice, cut once, either when cutting that plank, or altering
that firewall rule-set, or sending an email to a mailing list read by
hundreds of thousands of busy security engineers.

In the Elder Days, it was standard etiquette to read the archives of a
mailing list for a while before either subscribing or posting, so as to
learn whether the list was relevant  interesting without bothering its
thousands of regular readers with junk.  Sadly these courtesies seem
to be falling by the wayside.  Harumph :)

Ah well - yes, back to your regular programmes.

Cheers
Nick
-- 
Never FDISK after midnight


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140627164521.7...@glimmer.adsl24.co.uk

Re: Compromising Debian Repositories

2013-08-03 Thread Nick Boyce

On Saturday 03 Aug 2013 20:33:03 Robert Tomsick wrote:
 On 08/03/13 13:36, Rick Moen wrote:
[...]
  Indeed, this whole line of query (from someone who cannot even bother to
  read debian-legal and wants to be CCed; no thanks) is basically pretty
  dumb 
[...]
 
 I'm not sure that hostility is warranted.
 
 It still sparked a discussion, and it's definitely interesting to think
 about.

+1

Nick
-- 
Never FDISK after midnight


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201308040007.48832.n...@glimmer.adsl24.co.uk

Re: [SECURITY] [DSA 2695-1] chromium-browser security update

2013-06-02 Thread Nick Boyce

On Wednesday 29 May 2013 15:23:54 Michael Gilbert wrote:

 or possibly have unspecified other impact via unknown vectors.

I'm just wondering ... is that Google language for or possibly allow remote 
code execution ?

The phrase occurs for many of the vulnerabilities listed in the advisory, and 
most browser release notices cure some bugs that may allow remote code 
execution ... but not one of the vulnerabilities listed in this one refers to 
rce.  

I'm wondering whether the phrasing of the descriptions of the CVEs listed in 
this advisory is Google's choice .

And I'm thinking unspecified impact isn't very helpful really.

Cheers,
Nick
-- 
Never FDISK after midnight


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201306021432.14070.n...@glimmer.adsl24.co.uk

Re: [SECURITY] [DSA 2695-1] chromium-browser security update

2013-06-02 Thread Nick Boyce

On Sunday 02 Jun 2013 16:13:43 Michael Gilbert wrote:

 On Sun, Jun 2, 2013 at 9:32 AM, Nick Boyce wrote:
 
  On Wednesday 29 May 2013 15:23:54 Michael Gilbert wrote:
  
  or possibly have unspecified other impact via unknown vectors.
  
  I'm just wondering ... is that Google language for or possibly allow
  remote code execution ?
[...] 
 That is the intentionally vague language of CVE (e.g.
 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2837).
[...]
 In terms of chromium, your best bet is simply to wait for the bugs to
 become unembargoed (e.g.
 https://code.google.com/p/chromium/issues/detail?id=235638).

Thanks.  It's just that I tend to expect that by the time a security fix is 
released, those bugs *are* unembargoed, researchers are poring over code diffs, 
and clear descriptions are usually forthcoming cos there's no longer any point 
in being coy.  For instance, by the time a Firefox release is made Mozilla 
states explicitly in the release information whether or not each bug could 
cause rce.  Same thing for Microsoft.

It occurred to me maybe - for whatever reason - Google Corp has devised its 
own vocabulary for these things; sort of like Oracle Corp never calling a 
spade a spade in these matters.  Or the kernel team [ducks quickly] :)

I understand the Mitre people's predicament about the analysis workload though 
 [gulp].

Cheers,
Nick
-- 
Firefox 3.6? Dude we're on 8.0 now. You're like 3 weeks behind !


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201306021651.47286.n...@glimmer.adsl24.co.uk

Re: [SECURITY] [DSA 2162-1] openssl security update

2011-02-14 Thread Nick Boyce

On 14/02/2011 16:28, Nico Golde wrote:

 We recommend that you upgrade your invalid memory access packages.
 
 This has been a mistake during the auto-generation of the DSA template. Of 
 course thsi should say your openssl packages.

[ahem]

Erm ... missing .. [cough] .. exit-status check in the script which
generates and mails the DSAs ?

Need a security-team volunteer to go through the admin code-base looking
at these things ?

Cheers
Nick


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d59c839.3080...@glimmer.adsl24.co.uk

Re: Lenny version info

2010-12-16 Thread Nick Boyce

[sigh] ... okay

On 15/12/2010 12:00, John Keimel wrote:

 http://tinyurl.com/2b3g2l4
 
 Also, since you need it:
 
 http://tinyurl.com/ybpctcz
 
 Please particularly note items on jeopardy reply or Top posting
 and trimming.

+1

Nick
-- 
 Posting at the top because that's where the cursor happened to
  be is like shitting in your pants because that's where your
  asshole happened to be.  -- Andreas Prilop (c.i.w.a.h)


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d0ad6b6.2070...@glimmer.adsl24.co.uk

Heads-up: EXIM remote root exploit published

2010-12-11 Thread Nick Boyce

Just FYI: http://seclists.org/fulldisclosure/2010/Dec/222
contains a Perl script claimed to be based on the Metasploit module.

Contains this comment:
  #Exim 4.63 (RedHat/Centos/Debian) Remote Root Exploit by Kingcope

Untested by me.

Cheers
Nick Boyce
-- 
I like paying taxes. With them I buy civilization.


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d03a0e9.2080...@glimmer.adsl24.co.uk

Re: Debian and recent TCP vulnerability

2009-09-11 Thread Nick Boyce

Mlor Apac wrote:

 What's the status of debian (and linux kernel in general) regarding this
 recent TCP vulnerability? I have been unable to find any precise
 information. 

I too am wondering about this.

The basic Linux stance is presumably that stated in the Redhat advisory
you referenced :
http://kbase.redhat.com/faq/docs/DOC-18730

  Due to upstream's decision not to release
  updates, Red Hat do not plan to release updates
  to resolve these issues

Microsoft's bulletin
http://www.microsoft.com/technet/security/Bulletin/MS09-048.mspx
for the same problem-set is similarly half-hearted :

  The architecture to properly support TCP/IP
  protection does not exist on Microsoft
  Windows 2000 systems, making it infeasible to
  build the fix ... To do so would require
  rearchitecting a very significant amount of
  ... Microsoft Windows 2000

  By default, Windows XP [does] not have a
  listening service configured in the
  client firewall and [is] therefore not affected
  by this vulnerability ... [what kind of
  answer is that !] ... a system would become
  unresponsive due to memory consumption ...
  the system will recover once the flood ceases
   Microsoft recommends [customers] use
  [a firewall] to block access to the
  affected ports.

[duh]Using a firewall to block access to listening ports is no use at
all as a solution for a system which runs services which must remain
accessible.[/duh]

I'm guessing the Linux kernel folks' stance is some combination of the
above Microsoft statements, but haven't found any significant discussion
of it yet.  Redhat's recommendation is also to use firewalling to
mitigate the problem (though admittedly 'iptables' features are better
able to help than those of most firewalls [AFAIK]).

I worried about this bit :

  The following iptables example [ensures that]
  if 10 connection attempts to any TCP port are
  received within 5 minutes, they are dropped

Imagine how quickly that limit of 10 TCP connections in 5 minutes would
be reached by a web browser talking to a web service - especially if the
browser wasn't using HTTP 1.1 pipelining for some reason (proxy issues ?).

Cheers
Nick Boyce
-- 
But if we find we have left our bones to bleach in these desert
sands for nothing, beware the fury of the legions...
  -- Centurion in a letter home from North Africa
 3rd Century


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver

2008-07-08 Thread Nick Boyce


Debian Security Team wrote:


At this time, it is not possible to implement the recommended
countermeasures in the GNU libc stub resolver.  The following
workarounds are available:

1. Install a local BIND 9 resolver on the host, possibly in
forward-only mode.  


Uh .. is there any documentation on how to do that ?  Although I run a 
BIND 9 nameserver I don't know how to extract the BIND 9 resolver from 
such a system (for use on other systems) - and there doesn't seem to be 
any actual stand-alone package for such a thing.


Also, which Debian systems would otherwise use the libc stub resolver ? 
 All systems which *don't* have BIND installed ?


Cluebats welcome.

Cheers
Nick Boyce
--
Leave the Olympics in Greece, where they belong.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [SECURITY] [DSA 1571-1] New openssl packages fix predictable random number generator

2008-05-13 Thread Nick Boyce


Jan Luehr wrote:

However, I'm  curious: [how] could this happen? 


This is the best explanation I've seen so far :
http://it.slashdot.org/comments.pl?sid=551636cid=23392602

I have no idea if it's correct, but it sounds very plausible.

If there was any mistake it may have been to try too hard to get a 
warning-free run from valgrind.


Contrary to some reports that Debian should have discussed the proposed 
faulty fix with the OpenSSL devs in 2006, note that the Debian developer 
involved *did* try to discuss the proposed changes with the OpenSSL 
devs, and was not warned against the idea : 
http://marc.info/?t=11465108893r=1w=2


As the /. post says, Hats off to the reviewer who picked up on the 
problem.


Cheers,
Nick Boyce
--
Leave the Olympics in Greece, where they belong.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: ClamAV And unrar - Bug #465207

2008-02-27 Thread Nick Boyce


Stephen Gran wrote:


This one time, at band camp, Nick Boyce said:


.. it seems to me that simply enabling the --unrar parameter of 
clamscan would not entail incorporating or distributing any unrar code 
at all - the code to parse the --unrar parameter and call the non-free 
unrar binary if specified surely belongs to ClamAV alone ?


Yes, it's a known issue that I'm talking to upstream about.  If you want
to update the bug, feel free.  I really should have updated the bug
report to say:

There is a hard coded path in clamscan that calls internal unpackers
for zip and rar before trying the specified external unpackers.  This
breaks rar and some zip scanning for no clearly good reason.  I am
talking with upstream about it.


Ah .. thanks very much for the explanation .. the code sounds weird :)

Shouldn't it :
 call the external unpackers if specified
else call the internal unpackers if compiled in
else skip ?
[i.e. treat any specified external unpacker as an override to any 
available internal one]


I've added my comment to the bug ... good luck with upstream.

Cheers
Nick Boyce
--
Music began with a howl lamenting a loss.  The howl became
a prayer, and from the hope in the prayer started music.
  -- John Berger


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: ClamAV And unrar - Bug #465207

2008-02-27 Thread Nick Boyce


Stefan Fritsch wrote:


On Wednesday 27 February 2008, Nick Boyce wrote:



But it seems to me that simply enabling the --unrar parameter of
clamscan would not entail incorporating or distributing any unrar
code at all - the code to parse the --unrar parameter and call the
non-free unrar binary if specified surely belongs to ClamAV alone ?


Note that unrar-nonfree has no security support (like all packages in 
non-free) . Using it to automatically process potentially malicious 
content is a bad idea, IMHO. In fact, unrar-nonfree in stable had a 
security issue until the release of etch r3 (CVE-2007-0855).


Ah ... damn, didn't realise that - a bit like Ubuntu's universe I 
suppose ... security fixes not guaranteed, but are possible as the 
source is available.


Don't know what to do now, especially as this is currently still a Sarge 
system :-(   I might just disable RAR scanning till I upgrade it.


Thanks for the heads up.
Nick Boyce
--
The owls are not what they seem.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

ClamAV And unrar - Bug #465207

2008-02-26 Thread Nick Boyce

I'm trying to understand the situation with the Debian Volatile package 
of ClamAV and its lack of unrar support. I just found bug #465207 in 
which Torsten Jerzembeck asked for the package to have the ability to 
call unrar enabled - the maintainer replied that he is unable to do that 
because the unrar code is not redistributable ...


But it seems to me that simply enabling the --unrar parameter of 
clamscan would not entail incorporating or distributing any unrar code 
at all - the code to parse the --unrar parameter and call the non-free 
unrar binary if specified surely belongs to ClamAV alone ?


Thus the ClamAV package(s) could remain pure and free, while individual 
sysadmins could make their own decision about whether to install the 
non-free unrar binary package, and then request that clamscan call it.


I'm contemplating updating the bug report to say exactly this, but 
wondering whether I'm missing something ... All opinions gratefully 
received.


[We run clamscan nightly against a large amount of file storage used as 
a Samba share by Windows-based engineers all around the UK - and they 
seem to store a *lot* of RAR files there.  I realise we could compile up 
our own ClamAV, but I'd rather stick with Debian ...]


[1] http://bugs.debian.org/465207

Cheers
Nick Boyce
--
Microsoft suggests that users do not open or save Word files


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [DSA 1466-1] New xorg-server packages fix several vulnerabilities

2008-01-18 Thread Nick Boyce

Slight typo :

 For the oldstable distribution (etch), this problem has been
 fixed in version 4.3.0.dfsg.1-14sarge6 of xfree86.

s/etch/sarge/

Nick Boyce
-- 
If you don't pray in my school, I won't think in your church


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

UPDATE: Remote Root In Nvidia xserver Driver

2006-11-10 Thread Nick Boyce

Regarding my post here on 18.Oct.2006:
http://lists.debian.org/debian-security/2006/10/msg00046.html

Nvidia has published a bulletin on this security hole :
http://nvidia.custhelp.com/cgi-bin/nvidia.cfg/php/enduser/std_adp.php?p_faqid=1971
(dated 20th.Oct - sorry, only just found it)

Here are some salient points :

 * NVIDIA confirms that there is a security vulnerability in the NVIDIA 
UNIX Graphics drivers, versions 1.0-8762 and 1.0-8774, as reported in 
Security Advisory R7-0025, Buffer Overflow in NVIDIA Binary Graphics Driver 
For Linux (http://download2.rapid7.com/r7-0025/). 
 
 * This bug was in the NVIDIA X driver's Render acceleration layer.  The 
bug can be avoided in affected drivers by disabling Render acceleration via 
the RenderAccel X configuration option.
 
 * NVIDIA can confirm that this bug is only present in the NVIDIA UNIX 
Graphics drivers 1.0-8762 and 1.0-8774, and is fixed starting with 
1.0-8776.  Also, this bug is not present in driver versions older than 
1.0-8762

 * We encourage users of NVIDIA graphics driver version 1.0-8762  or 
1.0-8774 to upgrade to 1.0-8776, available here: 
http://www.nvidia.com/object/unix.html 
 
So while Etch and Sid users may want to observe that last advice (I don't know 
what the current state of packaging is for this driver there),  those of us 
using Sarge can just go back to using the packaged Nvidia graphics driver - 
1.0-7174 - because it doesn't contain the security hole.  Great !   

/me thanks lucky stars this bit of Debian stable is so far behind the bleeding 
edge :-)

Nick Boyce
Bristol, UK
-- 
Will no one rid me of this troublesome chair ?

Remote Root In Nvidia xserver Driver

2006-10-17 Thread Nick Boyce

Regarding the remote root hole in Nvidia's closed-source binary xserver driver 
announced today by Rapid7 :
  http://download2.rapid7.com/r7-0025/
and being discussed all over the place :
  http://it.slashdot.org/article.pl?sid=06/10/16/2038253
  http://kerneltrap.org/node/7228
it looks to me as though the hole is not present in the version of the driver 
packaged for Sarge (1.0.7174).  The Rapid7 bulletin asserts the hole is 
present in Linux driver versions 8762 and 8774 - and _probably_ earlier 
versions.

When I tried the PoC URL given at KernelTrap using a vanilla Sarge 
installation with the v7174 driver, KDE 3.3.2 and Konqueror my xserver did 
*not* crash - instead I saw this :

  An error occurred while loading http://nvidia.com/content/license/:

  Connection to host nvidia.com is broken.

Just for the sake of calm (my calm) can anyone else confirm this ?

NB: although some are saying this is a local root exploit only, the bulletin 
points out it can be exploited by visiting a malicious webpage.

Cheers
Nick Boyce
-- 
Will no one rid me of this troublesome chair ?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [SECURITY] [DSA 1156-1] New kdebase packages fix information disclosure

2006-09-01 Thread Nick Boyce


Florian Weimer wrote:

* Nick Boyce:


For interest, can anyone explain why a problem with kdm leads to the
need to reissue so many KDE packages ?


Security updates a performed on per source package (after all, we need
to ship an updated source package to comply with the DFSG and various
licenses).  The source package building KDE also builds tons of other
packages.


Um .. okay, thanks for explaining that. I should have thought of that 
... except that seems a pretty weird idea - to bundle so much source 
code into one monster kde-guts source package.


It makes sense (to me) to bundle closely related source together - but 
isn't it a bit self-defeating to bundle so many disparate program 
sources (kate, konsole, konqueror ...) into the same source package as 
such a small thing as kdm ?


I don't mean to complain - not being a developer I may well not be aware 
of some very good reason for it - but the pain that ensues for people 
like me, on dial-up links (don't ask ...), when we must download so many 
binaries just because something small like kdm has changed, is non-trivial.


If there's a stock explanation you can point me to I'd be grateful for 
the education.


Cheers
Nick Boyce
Bristol, UK


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [SECURITY] [DSA 1156-1] New kdebase packages fix information disclosure

2006-09-01 Thread Nick Boyce


Nick Boyce wrote:

I don't mean to complain - not being a developer I may well not be aware 
of some very good reason for it - but the pain that ensues for people 
like me, on dial-up links (don't ask ...), when we must download so many 
binaries just because something small like kdm has changed, is non-trivial.


If there's a stock explanation you can point me to I'd be grateful for 
the education.


Sorry everybody - I realise this is now probably OT for this list and I 
should take it to debian-kde.


Nick Boyce
Bristol, UK


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [SECURITY] [DSA 1156-1] New kdebase packages fix information disclosure

2006-08-30 Thread Nick Boyce

/updates/main/k/kdebase/ktip_3.3.2-1sarge3_i386.deb
   Size/MD5 checksum:79680 966842fe7926161702a92f1907ec309c
 
 http://security.debian.org/pool/updates/main/k/kdebase/kwin_3.3.2-1sarge3_i386.deb
   Size/MD5 checksum:   854870 5cf7be0a787c73b26fc3c7161a1de866
 
 http://security.debian.org/pool/updates/main/k/kdebase/libkonq4_3.3.2-1sarge3_i386.deb
   Size/MD5 checksum:   249494 2b43b65830f35ea3619ff8596340031d
 
 http://security.debian.org/pool/updates/main/k/kdebase/libkonq4-dev_3.3.2-1sarge3_i386.deb
   Size/MD5 checksum:44922 d07fda73f6365a4470db2ac21030c906

Cheers,
Nick Boyce
Bristol, UK
-- 
'If you don't pray in my school, I won't think in your church'


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [SECURITY] [DSA 952-1] New libapache-auth-ldap packages fix arbitrary code execution

2006-01-29 Thread Nick Boyce

On Sat, 28 Jan 2006 13:56:50 +0100, Florian Weimer wrote:

 * Nick Boyce:
 
 From this I infer that mod_auth_ldap for Debian-packaged Apache 2 must
  be included with the main Debian Apache packages, and that no
  libapache(2)-auth-ldap package is required - and that I therefore need
  fixed Apache 2 packages.  Is this so ?
 
 Apache 2 comes with its own LDAP module, which may have shared a
 common code base once (the Dave Carrigan is listed as author, too),
 but the vulnerable function is not present in version 2.0.55-4.  I
 haven't looked at other versions.

Ah .. thats good to know.  Thanks a lot for looking into it.  I had
looked around for Apache mod/auth/ldap modules when originally
setting the server up, and found there are several alternatives on the
Net by different authors. Without looking at any of the source code I
guessed for some reason that the mod_auth_ldap packaged with Apache
1.3.x was the one by Muhammad A Muquit, who's also written a version
for Apache 2.  I'd better get the source deb for 2.0.54 and have a
quick look.

Cheers,
Nick Boyce
Bristol, UK
-- 
It's always darkest just before you step on the cat.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: possible samba security problem

2005-01-28 Thread Nick Boyce

On Fri, 28 Jan 2005 20:43:30 +0100, Nils Juergens wrote:

On Fri, 28.01.05, Thorsten Giese [EMAIL PROTECTED] wrote:

I think it is considered good practice not to have users on important
systems in the first place, so maybe you should be thinking about how to get
your users off of your server.

Disagree disagree disagree ..

Leaving aside personal workstations, and resource-server-type systems,
there's a huge category of systems that will potentially (and quite
normally) have unprivileged users (that's what computing services are
all about).  In the corporate world anyway.

And good practice in such circumstances dictates that we only allow
ordinary users to see what they need to see.

The best solution to this issue would be to have smbstatus enhanced to
only show status information relating to the calling (unprivileged)
user.  But in lieu of that (a task for the Samba team) I think it
should be okay to simply change the permissions on
/var/run/samba/locking.tdb so only root can access it.  There's no
real need for ordinary users to use smbstatus anyway.  IMHO.

Nick Boyce
Bristol, UK
--
Expert, n.: Someone who comes from out of town and shows slides


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Updating Kernel Using make-kpkg - Not Intuitive ?

2004-03-22 Thread Nick Boyce

On Mon, 22 Mar 2004 12:27:52 -0700, Stephen Keeling wrote:

Incoming from Nick Boyce:
 
 Otherwise, I suggest you move /lib/modules/2.4.18 out of the way,
 perhaps to /lib/modules/2.4.18.old or something, and then try
 re-installing this image.
 [snip]
 What on earth is this trying to say to me ?

Hi.  This is the kernel install helper thingy.  As I've detected that
you did NOT move your old kernel modules to somewhere safe before
trying to install new ones (as anyone familiar with kernel installs
would have done), I'm bound to offer you the chance to save your butt
and do it now.  'Kay?  Otherwise, I'm about to clobber something
potentially important.

Well, yes ... I guess I'm just trying to point out (like you did)
there are n better ways to express it, in a third of the wordage.  And
it might be nice of the make-kpkg thingy to just do the deed for you.

Thanks
Nick Boyce
Bristol, UK
--
Baruch's Observation:
If all you have is a hammer, everything looks like a nail.

Re: Updating Kernel Using make-kpkg - Not Intuitive ?

2004-03-22 Thread Nick Boyce

On Mon, 22 Mar 2004 12:27:52 -0700, Stephen Keeling wrote:

Incoming from Nick Boyce:
 
 Otherwise, I suggest you move /lib/modules/2.4.18 out of the way,
 perhaps to /lib/modules/2.4.18.old or something, and then try
 re-installing this image.
 [snip]
 What on earth is this trying to say to me ?

Hi.  This is the kernel install helper thingy.  As I've detected that
you did NOT move your old kernel modules to somewhere safe before
trying to install new ones (as anyone familiar with kernel installs
would have done), I'm bound to offer you the chance to save your butt
and do it now.  'Kay?  Otherwise, I'm about to clobber something
potentially important.

Well, yes ... I guess I'm just trying to point out (like you did)
there are n better ways to express it, in a third of the wordage.  And
it might be nice of the make-kpkg thingy to just do the deed for you.

Thanks
Nick Boyce
Bristol, UK
--
Baruch's Observation:
If all you have is a hammer, everything looks like a nail.

Updating Kernel Using make-kpkg - Not Intuitive ?

2004-03-20 Thread Nick Boyce

 ...

It's a weird mixture of advice for the terminally stupid, and advice for 
the kernel super-guru :

   Reboot as soon as this install is finished (Do not 
   reboot right now, since you may not be able to boot 
   back up until installation is over, but boot immediately 
   after)

Indeed.

I realise this post is mostly off-topic on debian-security, so if anyone 
can advise me of a better forum for my observation I'd be grateful.   

debian-user ?   debian-dpkg ?
Maybe a usability bug filed against make-kpkg ?
Or maybe I'm missing some point, and the above comments belong in the 
trash.

Comments/flames welcome.

Cheers
Nick Boyce
Bristol, UK


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Updating Kernel Using make-kpkg - Not Intuitive ?

2004-03-20 Thread Nick Boyce

 ...

It's a weird mixture of advice for the terminally stupid, and advice for 
the kernel super-guru :

   Reboot as soon as this install is finished (Do not 
   reboot right now, since you may not be able to boot 
   back up until installation is over, but boot immediately 
   after)

Indeed.

I realise this post is mostly off-topic on debian-security, so if anyone 
can advise me of a better forum for my observation I'd be grateful.   

debian-user ?   debian-dpkg ?
Maybe a usability bug filed against make-kpkg ?
Or maybe I'm missing some point, and the above comments belong in the 
trash.

Comments/flames welcome.

Cheers
Nick Boyce
Bristol, UK

OpenSSL version command

2004-03-19 Thread Nick Boyce

Slightly topical question ... I just installed the OpenSSL security 
update, and then fired it up ... and asked it what its version is :

  OpenSSL version
  OpenSSL 0.9.6c 21 dec 2001

  glimmer:~$ dpkg -l openssl
  ii  openssl   0.9.6c-2.woody.6  Secure Socket Layer (SSL) ..

and wondered ... shouldn't it really identify itself a little better 
than that ?

Couldn't it say something like 
  OpenSSL version
  OpenSSL 0.9.6c - Debian 19 jan 2004
or even 
  OpenSSL version
  OpenSSL 0.9.6c 21 dec 2001 (Debian 19 jan 2004)
if it must ?

I'm a great believer in software being helpful ... when you ask it 
things :)

Nick Boyce
Bristol, UK


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: OpenSSL version command

2004-03-19 Thread Nick Boyce

On Saturday 20 Mar 2004 1:56 am, Nick Boyce wrote:

 Couldn't it say something like
   OpenSSL version
   OpenSSL 0.9.6c - Debian 19 jan 2004

I meant  19 mar 2004 ...
It's been a long day :-/

Cheers,
Nick Boyce
Bristol, UK


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

OpenSSL version command

2004-03-19 Thread Nick Boyce

Slightly topical question ... I just installed the OpenSSL security 
update, and then fired it up ... and asked it what its version is :

  OpenSSL version
  OpenSSL 0.9.6c 21 dec 2001

  glimmer:~$ dpkg -l openssl
  ii  openssl   0.9.6c-2.woody.6  Secure Socket Layer (SSL) ..

and wondered ... shouldn't it really identify itself a little better 
than that ?

Couldn't it say something like 
  OpenSSL version
  OpenSSL 0.9.6c - Debian 19 jan 2004
or even 
  OpenSSL version
  OpenSSL 0.9.6c 21 dec 2001 (Debian 19 jan 2004)
if it must ?

I'm a great believer in software being helpful ... when you ask it 
things :)

Nick Boyce
Bristol, UK

Re: OpenSSL version command

2004-03-19 Thread Nick Boyce

On Saturday 20 Mar 2004 1:56 am, Nick Boyce wrote:

 Couldn't it say something like
   OpenSSL version
   OpenSSL 0.9.6c - Debian 19 jan 2004

I meant  19 mar 2004 ...
It's been a long day :-/

Cheers,
Nick Boyce
Bristol, UK

How To Set Up Mail-out-only System ?

2004-02-10 Thread Nick Boyce

Sorry if this is a dumb question ...

I've just set up a secure (you know .. more than usual) Debian system, 
and want to arrange things so that it can send mail out when necessary 
(in case anything happens that it thinks I should know about) but is 
*not* constantly listening for incoming mail.

Is there a best way of doing this ?

The default Exim MTA is installed, and I've commented out the SMTP line 
from inetd.conf, but there is a /etc/init.d/exim startup script that 
comes with the Exim package, that has this :

   # Exit if exim runs from /etc/inetd.conf
   if [ -f /etc/inetd.conf ]  grep -q ^ *smtp /etc/inetd.conf; then
   exit 0
   fi
   [...]
   case $1 in
 start)
   echo -n Starting MTA: 
   start-stop-daemon --start --pidfile /var/run/exim/exim.pid \
   --exec $DAEMON -- -bd -q30m

So one way or the other, Exim gets to listen.

In exim.conf, there is 
   # This will cause it to accept mail only from the local interface
   #local_interfaces = 127.0.0.1
so I could set that option.  Would that stop Exim from binding to the 
ethernet interface ?

Should I just remove the S20exim symlink from rc?.d ?
That seems a bit of a kludge.  If this was NetBSD, I'd set something 
like exim=no in somewhere like rc.conf ... is there a Debian 
equivalent to that ?

TIA for any advice.
Nick Boyce
Bristol, UK


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: How To Set Up Mail-out-only System ?

2004-02-10 Thread Nick Boyce

On Wed, 11 Feb 2004 11:53:38 +1000, Clayton Russell wrote:

On Wed, 2004-02-11 at 11:41, Nick Boyce wrote:
 Sorry if this is a dumb question ...
 
 I've just set up a secure (you know .. more than usual) Debian system, 
 and want to arrange things so that it can send mail out when necessary 
 (in case anything happens that it thinks I should know about) but is 
 *not* constantly listening for incoming mail.

If you would like to use postfix you can comment out the 
smtp  inet  n   -   n   -   -   smtpd
line in /etc/postfix/master.cf, which stops the daemon listening on port
25, but does not affect sending mail.

Thanks Clayton - that's very useful - I was planning to look at
Postfix in due course - it seems to have the best security pedigree of
any of the popular MTAs.
[Without wanting to start anything religious here :-)]

Much obliged
Nick
-- 
Bother, said Pooh, as he struggled with sendmail.cf, it never
does quite what I want.  I wish Christopher Robin was here.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: How To Set Up Mail-out-only System ?

2004-02-10 Thread Nick Boyce

On Wed, 11 Feb 2004 01:41:13 +, I wrote:

I've just set up a secure (you know .. more than usual) Debian system, 
and want to arrange things so that it can send mail out when necessary 
(in case anything happens that it thinks I should know about) but is 
*not* constantly listening for incoming mail.

Is there a best way of doing this ?

Thanks for all the great advice, people.

The idea of removing the -bd switch from the Exim startup line in
/etc/init.d/exim is appealing, though I guess I'd have to remember to
make that amendment every time a major upgrade occurred ... in that
context, I suppose editing exim.conf is more correct, in that
upgrades should offer me the chance to keep my customised exim.conf.

I'd rather stay with a mainstream MTA than switch to a smaller
dedicated null mailer, on the premise that mainstream MTAs will stay
better maintained - though the smaller attack surface of the dedicated
mailers is a Good Thing I suppose.

I may need timely notifications from this box (ok, it's an IDS), so I
don't want to rely on periodic cron-initiated mailer runs.

Again, many thanks for all the help.

Nick Boyce
Bristol, Uk
-- 
We did a risk management review.  We concluded that there was no risk
 of any management.
 -- Hugo Mills [EMAIL PROTECTED]


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

How To Set Up Mail-out-only System ?

2004-02-10 Thread Nick Boyce

Sorry if this is a dumb question ...

I've just set up a secure (you know .. more than usual) Debian system, 
and want to arrange things so that it can send mail out when necessary 
(in case anything happens that it thinks I should know about) but is 
*not* constantly listening for incoming mail.

Is there a best way of doing this ?

The default Exim MTA is installed, and I've commented out the SMTP line 
from inetd.conf, but there is a /etc/init.d/exim startup script that 
comes with the Exim package, that has this :

   # Exit if exim runs from /etc/inetd.conf
   if [ -f /etc/inetd.conf ]  grep -q ^ *smtp /etc/inetd.conf; then
   exit 0
   fi
   [...]
   case $1 in
 start)
   echo -n Starting MTA: 
   start-stop-daemon --start --pidfile /var/run/exim/exim.pid \
   --exec $DAEMON -- -bd -q30m

So one way or the other, Exim gets to listen.

In exim.conf, there is 
   # This will cause it to accept mail only from the local interface
   #local_interfaces = 127.0.0.1
so I could set that option.  Would that stop Exim from binding to the 
ethernet interface ?

Should I just remove the S20exim symlink from rc?.d ?
That seems a bit of a kludge.  If this was NetBSD, I'd set something 
like exim=no in somewhere like rc.conf ... is there a Debian 
equivalent to that ?

TIA for any advice.
Nick Boyce
Bristol, UK

Re: How To Set Up Mail-out-only System ?

2004-02-10 Thread Nick Boyce

On Wed, 11 Feb 2004 11:53:38 +1000, Clayton Russell wrote:

On Wed, 2004-02-11 at 11:41, Nick Boyce wrote:
 Sorry if this is a dumb question ...
 
 I've just set up a secure (you know .. more than usual) Debian system, 
 and want to arrange things so that it can send mail out when necessary 
 (in case anything happens that it thinks I should know about) but is 
 *not* constantly listening for incoming mail.

If you would like to use postfix you can comment out the 
smtp  inet  n   -   n   -   -   smtpd
line in /etc/postfix/master.cf, which stops the daemon listening on port
25, but does not affect sending mail.

Thanks Clayton - that's very useful - I was planning to look at
Postfix in due course - it seems to have the best security pedigree of
any of the popular MTAs.
[Without wanting to start anything religious here :-)]

Much obliged
Nick
-- 
Bother, said Pooh, as he struggled with sendmail.cf, it never
does quite what I want.  I wish Christopher Robin was here.

Re: How To Set Up Mail-out-only System ?

2004-02-10 Thread Nick Boyce

On Wed, 11 Feb 2004 01:41:13 +, I wrote:

I've just set up a secure (you know .. more than usual) Debian system, 
and want to arrange things so that it can send mail out when necessary 
(in case anything happens that it thinks I should know about) but is 
*not* constantly listening for incoming mail.

Is there a best way of doing this ?

Thanks for all the great advice, people.

The idea of removing the -bd switch from the Exim startup line in
/etc/init.d/exim is appealing, though I guess I'd have to remember to
make that amendment every time a major upgrade occurred ... in that
context, I suppose editing exim.conf is more correct, in that
upgrades should offer me the chance to keep my customised exim.conf.

I'd rather stay with a mainstream MTA than switch to a smaller
dedicated null mailer, on the premise that mainstream MTAs will stay
better maintained - though the smaller attack surface of the dedicated
mailers is a Good Thing I suppose.

I may need timely notifications from this box (ok, it's an IDS), so I
don't want to rely on periodic cron-initiated mailer runs.

Again, many thanks for all the help.

Nick Boyce
Bristol, Uk
-- 
We did a risk management review.  We concluded that there was no risk
 of any management.
 -- Hugo Mills [EMAIL PROTECTED]

Re: Hacked - is it my turn?

2004-02-02 Thread Nick Boyce

On Mon, 2 Feb 2004 18:28:31 -0800 (PST), Alvin Oga wrote:

On Mon, 2 Feb 2004, Johannes Graumann wrote:

   Checking 'bindshell'... INFECTED [PORTS:  1524 31337]
 At this point I believe to be able to attribute this to portsentry
 running - '/etc/init.d/portsentry stop' makes it go away,

odd that portsentry does that... oh welll ... 

Um, no - I believe that's not odd at all - because Port Sentry's
method is to listen on every conceivable port so that it can detect
inbound connection attempts.  NB: this is just hearsay - I've never
actually used Port Sentry, due to reports about this very problem.  In
fact, IIUC you also need to have all those ports unfirewalled so that
Port Sentry can do its stuff.  Quite a few people think this is a Very
Bad Thing ... and that's been good enough for me.

[And then there's Port Sentry's attack-response feature, which can
apparently leave you deaf dumb  blind if someone sends you spoofed
packets.   I _think_ the current wisdom is that Port Sentry is an all
round Bad Idea, but maybe it's just a religious thing ..]

Somebody please tell me if I'm wrong here.

Nick Boyce
Bristol, UK
-- 
I tried to patent patent barratry as a business model, 
but there was too much prior art.

Re: Infrastructer back online?

2004-01-09 Thread Nick Boyce

On Wed, 7 Jan 2004 19:43:02 -0800, Matt Zimmerman wrote:

On Thu, Jan 08, 2004 at 04:08:23AM +0100, Martin Helas wrote:

 Am Mi Jan 07, 2004 at 06:5432 -0800 gab Matt Zimmerman [EMAIL PROTECTED] von sich:
  On Wed, Jan 07, 2004 at 10:35:30PM +0100, Jan L??hr wrote:
  
   noticing the increasing amount of secure-adv I'd like to ask, wheter the 
   buid-deamons are back or wheter another issue is increasing the amount of 
   advs rapidly.
  
  Everything is working again.
 
 what's about p.d.o ?

There is more than one p.d.o and only one of them is not operational.  That
has nothing to do with security, thankfully.

Erm .. people.debian.org is back online, though some people seem to be
missing from it.  And packages.debian.org is still offline, and its
homepage states :

  packages.debian.org is down at the moment.

  Please see this announcement 
  (http://www.debian.org/News/2003/20031121)
  for more details

Which is the announcement about the November compromise.
That makes it sound like it _is_ a security issue .. 

Nick Boyce
Bristol, UK
--
Ok spammer, I'll 'just hit delete'. You can be 'Delete'.
 --  Ron SuperTroll Ritzman, NANAE


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Infrastructer back online?

2004-01-09 Thread Nick Boyce

On Wed, 7 Jan 2004 19:43:02 -0800, Matt Zimmerman wrote:

On Thu, Jan 08, 2004 at 04:08:23AM +0100, Martin Helas wrote:

 Am Mi Jan 07, 2004 at 06:5432 -0800 gab Matt Zimmerman [EMAIL PROTECTED] 
 von sich:
  On Wed, Jan 07, 2004 at 10:35:30PM +0100, Jan L??hr wrote:
  
   noticing the increasing amount of secure-adv I'd like to ask, wheter the 
   buid-deamons are back or wheter another issue is increasing the amount 
   of 
   advs rapidly.
  
  Everything is working again.
 
 what's about p.d.o ?

There is more than one p.d.o and only one of them is not operational.  That
has nothing to do with security, thankfully.

Erm .. people.debian.org is back online, though some people seem to be
missing from it.  And packages.debian.org is still offline, and its
homepage states :

  packages.debian.org is down at the moment.

  Please see this announcement 
  (http://www.debian.org/News/2003/20031121)
  for more details

Which is the announcement about the November compromise.
That makes it sound like it _is_ a security issue .. 

Nick Boyce
Bristol, UK
--
Ok spammer, I'll 'just hit delete'. You can be 'Delete'.
 --  Ron SuperTroll Ritzman, NANAE

Re: Current Stable Kernel 2.4.18 Source deb ?

2004-01-04 Thread Nick Boyce

On Sat, 3 Jan 2004 11:16:26 +0100, Maurizio Lemmo wrote:

On sabato 03 gennaio 2004, alle 05:26, Nick Boyce wrote:
 I'd be grateful if someone could please try to deconfuse me about what
 the current stable kernel 2.4.18 source package is ..
 
 DSA 403-1 (http://www.debian.org/security/2003/dsa-403) states that
 the do_brk security hole was fixed in vanilla kernel 2.4.23, and that
 
   For Debian it has been fixed in version 2.4.18-12 of 
   the kernel source packages, version 2.4.18-14 of the 
   i386 kernel images and version 2.4.18-11 of the alpha 
   kernel images

I think this was simply a mistake. It's nonsense that image is more
update from the source it came from. I think they invert the version
number, in the mail message.

Thanks for your comment - that seems most likely to me too.

I've now looked back through the debian-security archive, and the
previous few kernel updates were :

DSA 358-1 (31.Jul.2003) == kernel-source-2.4.18-11 (multiple bugs)
DSA 358-2 ( 5.Aug.2003) == kernel-source-2.4.18-12 (fixes oops)
DSA 358-4 (13.Aug.2003) == kernel-source-2.4.18-13 (fixes oops)

so the new version can't be any less than 2.4.18-14, and DSA 403-1
must contain a typo/thinko.

I was just being ultra-paranoid, and double-checking everything in the
light of recent events.  I must calm down ;-)

It's my opinion, but, i think it's correct.

Yep - thanks again for the feedback.

Nick Boyce
Bristol, UK
--
Steinbach's Guideline for Systems Programming: 
Never test for an error condition you don't know how to handle.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Current Stable Kernel 2.4.18 Source deb ?

2004-01-04 Thread Nick Boyce

On Sat, 3 Jan 2004 11:16:26 +0100, Maurizio Lemmo wrote:

On sabato 03 gennaio 2004, alle 05:26, Nick Boyce wrote:
 I'd be grateful if someone could please try to deconfuse me about what
 the current stable kernel 2.4.18 source package is ..
 
 DSA 403-1 (http://www.debian.org/security/2003/dsa-403) states that
 the do_brk security hole was fixed in vanilla kernel 2.4.23, and that
 
   For Debian it has been fixed in version 2.4.18-12 of 
   the kernel source packages, version 2.4.18-14 of the 
   i386 kernel images and version 2.4.18-11 of the alpha 
   kernel images

I think this was simply a mistake. It's nonsense that image is more
update from the source it came from. I think they invert the version
number, in the mail message.

Thanks for your comment - that seems most likely to me too.

I've now looked back through the debian-security archive, and the
previous few kernel updates were :

DSA 358-1 (31.Jul.2003) == kernel-source-2.4.18-11 (multiple bugs)
DSA 358-2 ( 5.Aug.2003) == kernel-source-2.4.18-12 (fixes oops)
DSA 358-4 (13.Aug.2003) == kernel-source-2.4.18-13 (fixes oops)

so the new version can't be any less than 2.4.18-14, and DSA 403-1
must contain a typo/thinko.

I was just being ultra-paranoid, and double-checking everything in the
light of recent events.  I must calm down ;-)

It's my opinion, but, i think it's correct.

Yep - thanks again for the feedback.

Nick Boyce
Bristol, UK
--
Steinbach's Guideline for Systems Programming: 
Never test for an error condition you don't know how to handle.

Re: Current Stable Kernel 2.4.18 Source deb ?

2004-01-04 Thread Nick Boyce

On Sun, 4 Jan 2004 12:16:57 -0800, Matt Zimmerman wrote:

On Sat, Jan 03, 2004 at 05:26:41AM +, Nick Boyce wrote:

 DSA 403-1 (http://www.debian.org/security/2003/dsa-403) states that
 the do_brk security hole was fixed in vanilla kernel 2.4.23, and that
 
   For Debian it has been fixed in version 2.4.18-12 of 
   the kernel source packages, version 2.4.18-14 of the 
   i386 kernel images and version 2.4.18-11 of the alpha 
   kernel images
 
 But when I ran apt-get a couple of days ago, to upgrade my existing
 kernel-source package, what I got was version 2.4.18-14, rather than
 the 2.4.18-12 that the above implies.

This error in the advisory is corrected in the current version on the
website.

Thanks.

Nick Boyce
Bristol, UK
--
Steinbach's Guideline for Systems Programming: 
Never test for an error condition you don't know how to handle.

Current Stable Kernel 2.4.18 Source deb ?

2004-01-02 Thread Nick Boyce

I'd be grateful if someone could please try to deconfuse me about what
the current stable kernel 2.4.18 source package is ..

DSA 403-1 (http://www.debian.org/security/2003/dsa-403) states that
the do_brk security hole was fixed in vanilla kernel 2.4.23, and that

  For Debian it has been fixed in version 2.4.18-12 of 
  the kernel source packages, version 2.4.18-14 of the 
  i386 kernel images and version 2.4.18-11 of the alpha 
  kernel images

But when I ran apt-get a couple of days ago, to upgrade my existing
kernel-source package, what I got was version 2.4.18-14, rather than
the 2.4.18-12 that the above implies.

Specifically, what I got was
http://security.debian.org/pool/updates/main/k/kernel-source-2.4.18/kernel-source-2.4.18_2.4.18-14_all.deb

This source deb may well be Good Stuff, but how does it relate to the
security advisory ?   Does it mean there have been more fixes since
the DSA ?

TIA for any light anyone can shed.

Nick Boyce
Bristol, UK
-- 
We did a risk management review.  We concluded that there was no risk
 of any management.
 -- Hugo Mills [EMAIL PROTECTED]

Re: Attempts to poison bayesian systems

2003-12-23 Thread Nick Boyce

On Tue, 23 Dec 2003 13:25:30 +, Dale Amon wrote:

I've been noticing loads of mails like this lately:

  Date: Sun, 21 Dec 2003 16:25:34 +0500
  From: Joseph Jenkins [EMAIL PROTECTED]
  Subject: Re: MIT, rest in peace!
  To: [EMAIL PROTECTED]
  X-Mailer: mPOP Web-Mail 2.19

  emery atrocious larval drippy elate incontrollable raster anglicanism
  checkerberry feed sit ajar saturable decathlon
  already climate inhibition pagoda narcissus expository toni

Yes, I'm seeing lots of these too.  
A particular pattern is that subject line format you quoted : 
  Re: followed by a short uppercase word, followed by some 
  random lowercase nonsense (non-dictionary) words.  

What do you suppose _that's_ about ?
Can anyone think of a filter pattern to catch that ?

Also, almost without exception, there's a string of random dictionary
words in the body enclosed within font color=white/font tags,
followed by lots more included *as* tags - thus : 
  L0seangora weight/fuming rea/magnificentlly quickly

Actually, all the examples I'm seeing are HTML format, so easily
filtered on that basis - are you seeing plain-text versions ?

I can only assume someone out there is trying to attack
bayesian systems by loading them up with all sorts of
normal words so that good mail gets false positives, thus
breaking the systems.

That sounds plausible :-(

Merry Happy Season Of Jollyness everyone

Nick Boyce
Bristol, UK
--
The 2003 Perl Advent Calendar: http://perladvent.org/2003/

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Attempts to poison bayesian systems

2003-12-23 Thread Nick Boyce

On Tue, 23 Dec 2003 13:25:30 +, Dale Amon wrote:

I've been noticing loads of mails like this lately:

  Date: Sun, 21 Dec 2003 16:25:34 +0500
  From: Joseph Jenkins [EMAIL PROTECTED]
  Subject: Re: MIT, rest in peace!
  To: [EMAIL PROTECTED]
  X-Mailer: mPOP Web-Mail 2.19

  emery atrocious larval drippy elate incontrollable raster anglicanism
  checkerberry feed sit ajar saturable decathlon
  already climate inhibition pagoda narcissus expository toni

Yes, I'm seeing lots of these too.  
A particular pattern is that subject line format you quoted : 
  Re: followed by a short uppercase word, followed by some 
  random lowercase nonsense (non-dictionary) words.  

What do you suppose _that's_ about ?
Can anyone think of a filter pattern to catch that ?

Also, almost without exception, there's a string of random dictionary
words in the body enclosed within font color=white/font tags,
followed by lots more included *as* tags - thus : 
  L0seangora weight/fuming rea/magnificentlly quickly

Actually, all the examples I'm seeing are HTML format, so easily
filtered on that basis - are you seeing plain-text versions ?

I can only assume someone out there is trying to attack
bayesian systems by loading them up with all sorts of
normal words so that good mail gets false positives, thus
breaking the systems.

That sounds plausible :-(

Merry Happy Season Of Jollyness everyone

Nick Boyce
Bristol, UK
--
The 2003 Perl Advent Calendar: http://perladvent.org/2003/

Re: strange reboot on woody

2003-12-02 Thread Nick Boyce

On Sun, 30 Nov 2003 22:51:43 +0100, Bernd Eckenfels wrote:

if here is no entry on an loggen in user after that it looks pretty sure like CAD.

 I would but that is the only way I can let them safely reboot the machine
 (If I'll need them to) without giving the root password (although I know
 that it only take a few seconds to reboot from CD and change it.

You can give them a reboot user, whith a password, uid=0 and reoot or halt
as the command line

You could also call a script from inttiab on CAD, which is doing syslog before reboot.

Good idea .. in fact I wonder why that isn't the default behaviour
(the syslog entry on CAD).  Surely it's a negligible overhead, and can
only help - or at worst would be uninteresting ?   It certainly is the
default on some of the commercial Unixen that I administer (on some
flavours I can think of there is an optional message argument to the
shutdown command, that is logged as a reason: field of the syslog
entry).

Nick Boyce
Bristol, UK
-- 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: strange reboot on woody

2003-12-02 Thread Nick Boyce

On Sun, 30 Nov 2003 22:51:43 +0100, Bernd Eckenfels wrote:

if here is no entry on an loggen in user after that it looks pretty sure like 
CAD.

 I would but that is the only way I can let them safely reboot the machine
 (If I'll need them to) without giving the root password (although I know
 that it only take a few seconds to reboot from CD and change it.

You can give them a reboot user, whith a password, uid=0 and reoot or halt
as the command line

You could also call a script from inttiab on CAD, which is doing syslog before 
reboot.

Good idea .. in fact I wonder why that isn't the default behaviour
(the syslog entry on CAD).  Surely it's a negligible overhead, and can
only help - or at worst would be uninteresting ?   It certainly is the
default on some of the commercial Unixen that I administer (on some
flavours I can think of there is an optional message argument to the
shutdown command, that is logged as a reason: field of the syslog
entry).

Nick Boyce
Bristol, UK
-- 
A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?

Re: certificate server (ejbca)

2003-11-05 Thread Nick Boyce

On Tue, 4 Nov 2003 15:21:14 +0100 (CET), Henrik Andreasson wrote:

Here comes answers from the main developer Tomas Gustavsson

//Henrik Andreasson

If your out to get a larger CA server (works for smaller installations
too) check out ejbca, build on Enterprise Java Beans.

ejbca.sf.net / http://sourceforge.net/projects/ejbca
[...]
It's reliable. It's customizeable. It's modern (latest standards). I't s
easy to set up and testdrive. It's user friendly. It's actively
developed. It's cheap. It's embeddable. It's secure (hopefully :). And
it also has a great looking GUI :)
You can also point out that Java is a great language...

Okay, sounds great - but for those of us who don't have a J2EE server
to hand (no Tomcat, or Jakarta, or somesuch ?) is it fair to say that
this is *not* a simple CA solution ?Is it still easy to set up if
all you have is a plain Apache server to begin with ?   

Thanks,

Nick Boyce
Bristol, UK
--
... the fundamental design flaws are completely hidden by the
superficial design flaws.
Douglas Adams(1952 - 2001): So Long and Thanks For All The Fish.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: certificate server (ejbca)

2003-11-05 Thread Nick Boyce

On Tue, 4 Nov 2003 15:21:14 +0100 (CET), Henrik Andreasson wrote:

Here comes answers from the main developer Tomas Gustavsson

//Henrik Andreasson

If your out to get a larger CA server (works for smaller installations
too) check out ejbca, build on Enterprise Java Beans.

ejbca.sf.net / http://sourceforge.net/projects/ejbca
[...]
It's reliable. It's customizeable. It's modern (latest standards). I't s
easy to set up and testdrive. It's user friendly. It's actively
developed. It's cheap. It's embeddable. It's secure (hopefully :). And
it also has a great looking GUI :)
You can also point out that Java is a great language...

Okay, sounds great - but for those of us who don't have a J2EE server
to hand (no Tomcat, or Jakarta, or somesuch ?) is it fair to say that
this is *not* a simple CA solution ?Is it still easy to set up if
all you have is a plain Apache server to begin with ?   

Thanks,

Nick Boyce
Bristol, UK
--
... the fundamental design flaws are completely hidden by the
superficial design flaws.
Douglas Adams(1952 - 2001): So Long and Thanks For All The Fish.

Re: secure FTP clients [was: recommendations for FTP server]

2003-06-22 Thread Nick Boyce

On 21 Jun 2003 10:44:47 +0200, Florent Rougon wrote:

Nick Boyce [EMAIL PROTECTED] wrote:

   http://filezilla.sourceforge.net/
 
 GUI Win32 client that does FTP, FTP over SSL, and SFTP.  Apparently
 has some integration with PuTTY,though I can't currently figure out
 how to get FileZilla to use my PuTTY keystore.

The way I see it is:
  - I load (with Pageant) a key to log as $USER on $HOST
  - I fire filezilla and make an SFTP connection as $USER to $HOST
  - when prompted for the password, I just type garbage
  - the login is successful, meaning FileZilla used the key loaded by
Pageant to perform the authentication.

Thanks very much for that tip - I've tried this, and it works for me
too.  I guess the FileZilla people will be making this nicer when
they get the time.

Nick Boyce
Bristol, UK
--
Remember: 
If brute force doesn't work, you're just not using enough.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: secure FTP clients [was: recommendations for FTP server]

2003-06-22 Thread Nick Boyce

On 21 Jun 2003 10:44:47 +0200, Florent Rougon wrote:

Nick Boyce [EMAIL PROTECTED] wrote:

   http://filezilla.sourceforge.net/
 
 GUI Win32 client that does FTP, FTP over SSL, and SFTP.  Apparently
 has some integration with PuTTY,though I can't currently figure out
 how to get FileZilla to use my PuTTY keystore.

The way I see it is:
  - I load (with Pageant) a key to log as $USER on $HOST
  - I fire filezilla and make an SFTP connection as $USER to $HOST
  - when prompted for the password, I just type garbage
  - the login is successful, meaning FileZilla used the key loaded by
Pageant to perform the authentication.

Thanks very much for that tip - I've tried this, and it works for me
too.  I guess the FileZilla people will be making this nicer when
they get the time.

Nick Boyce
Bristol, UK
--
Remember: 
If brute force doesn't work, you're just not using enough.

Re: recommendations for FTP server

2003-06-20 Thread Nick Boyce

On Fri, 20 Jun 2003 16:25:30 -0400, Stephen Gran wrote:

This one time, at band camp, Matt Zimmerman said:
[...]
Yeah, that's what I have been thinking.  I was sort of hoping there was
something else out there that did all this besides sftp, because several
of my friends will be connecting from Windoze boxes.  I guess I'll just
point them to PuTTy and friends.

Don't forget FileZilla
  http://filezilla.sourceforge.net/

GUI Win32 client that does FTP, FTP over SSL, and SFTP.  Apparently
has some integration with PuTTY,though I can't currently figure out
how to get FileZilla to use my PuTTY keystore.

Seems nice and stable to me.

Nick Boyce
Bristol, UK
--
Microsoft may provide updates that will be automatically downloaded onto 
your computer. These updates may disable your ability to copy and/or play
content and use other software on your computer.
-- http://bsdvault.net/article.php?sid=527mode=order=0


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: recommendations for FTP server

2003-06-20 Thread Nick Boyce

On Fri, 20 Jun 2003 16:25:30 -0400, Stephen Gran wrote:

This one time, at band camp, Matt Zimmerman said:
[...]
Yeah, that's what I have been thinking.  I was sort of hoping there was
something else out there that did all this besides sftp, because several
of my friends will be connecting from Windoze boxes.  I guess I'll just
point them to PuTTy and friends.

Don't forget FileZilla
  http://filezilla.sourceforge.net/

GUI Win32 client that does FTP, FTP over SSL, and SFTP.  Apparently
has some integration with PuTTY,though I can't currently figure out
how to get FileZilla to use my PuTTY keystore.

Seems nice and stable to me.

Nick Boyce
Bristol, UK
--
Microsoft may provide updates that will be automatically downloaded onto 
your computer. These updates may disable your ability to copy and/or play
content and use other software on your computer.
-- http://bsdvault.net/article.php?sid=527mode=order=0

Re: Probable SSH Vulnerability

2003-06-17 Thread Nick Boyce

On Tue, 17 Jun 2003 21:34:32 +0200, Florian Weimer wrote:

Nick Boyce [EMAIL PROTECTED] writes:

These attacks require wiretapping and traffic
manipulation capabilities.  

 I'd be interested if you could expand on this - do you mean a
 connection to the victim's LAN is necessary ?

LAN or WAN.  Actually, access to any transmission link suffices.
[...]
... wiretapping WANs is not exactly straightforward. 8-) You
will have a hard time doing it even if you've compromised some
intermediate router.  In a true WAN environment, scalable
eavesdropping requires access to the physical medium and special
eavesdropping cards for the machines that perform the eavesdropping.

In our comms room at work there are many bits of various kinds of WAN
kit where our comms guys have fitted Y-cables into WAN ports so they
can plug in network analysers to diagnose problems ... I assume that
every comms room belonging to every operator on the Net has similar
arrangements, and I worry that it's not impossible for Bad Guys to
work in such places :)

But your points are all well taken, and I consider myself educated 
enlightened :)   Thanks.

Nick Boyce
Bristol, UK
--
Dinner is ready when the smoke alarm goes off.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Probable SSH Vulnerability

2003-06-17 Thread Nick Boyce

On Tue, 17 Jun 2003 21:34:32 +0200, Florian Weimer wrote:

Nick Boyce [EMAIL PROTECTED] writes:

These attacks require wiretapping and traffic
manipulation capabilities.  

 I'd be interested if you could expand on this - do you mean a
 connection to the victim's LAN is necessary ?

LAN or WAN.  Actually, access to any transmission link suffices.
[...]
... wiretapping WANs is not exactly straightforward. 8-) You
will have a hard time doing it even if you've compromised some
intermediate router.  In a true WAN environment, scalable
eavesdropping requires access to the physical medium and special
eavesdropping cards for the machines that perform the eavesdropping.

In our comms room at work there are many bits of various kinds of WAN
kit where our comms guys have fitted Y-cables into WAN ports so they
can plug in network analysers to diagnose problems ... I assume that
every comms room belonging to every operator on the Net has similar
arrangements, and I worry that it's not impossible for Bad Guys to
work in such places :)

But your points are all well taken, and I consider myself educated 
enlightened :)   Thanks.

Nick Boyce
Bristol, UK
--
Dinner is ready when the smoke alarm goes off.

Re: Probable SSH Vulnerability

2003-06-16 Thread Nick Boyce

On Sun, 15 Jun 2003 09:01:00 +0200, Florian Weimer wrote:

Tim Peeler [EMAIL PROTECTED] writes:

 I've come to the conclusion that the SSH1 protocol is the most
 likely cause of this problem.

Attacks on the SSH v1 protocol are relatively sophisticated.  It's
more likely that some token used for authentication (password, RSA or
DSA key) has leaked, that a machine used to access the attacked
machines has itself been compromised (e.g. a home machine of an
employee), or a trojanized OpenSSH versions exist on your local Debian
mirror.
[...]
These attacks require wiretapping and traffic
manipulation capabilities.  

I'd be interested if you could expand on this - do you mean a
connection to the victim's LAN is necessary ?

I'd have thought ability to intercept WAN traffic was enough, but I
don't really know what I'm talking about :-).  And AIUI, traffic
manipulation is a standard technique for a skilled Bad Guy (injecting
packets, fiddling with packets, connection hijacking).  The sort of
skill level required to perform a sequence number attack would do,
wouldn't it ? 

If the edge networks are trustworthy, ...

Again it sounds like you're saying LAN access is needed.

I recognise what you're saying about the more likely scenarios though
(stolen access tokens, etc). [ IIRC, the www.apache.org crack was done
that way (http://www.apacheweek.com/issues/01-06-01#hack) ]

 Why do you think you are so special?

But someone's got to be the first to fall prey to each new technique -
why not Tim ?

Or are you saying the computational effort involved is as huge as,
say, a DES crack would be ?  (i.e. only national security services and
mobsters would have the resources ?)

Cheers
Nick Boyce
Bristol, UK
--
Yousa steala precious from meesa! - Jar-Jaromir


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Probable SSH Vulnerability

2003-06-16 Thread Nick Boyce

On Sun, 15 Jun 2003 09:01:00 +0200, Florian Weimer wrote:

Tim Peeler [EMAIL PROTECTED] writes:

 I've come to the conclusion that the SSH1 protocol is the most
 likely cause of this problem.

Attacks on the SSH v1 protocol are relatively sophisticated.  It's
more likely that some token used for authentication (password, RSA or
DSA key) has leaked, that a machine used to access the attacked
machines has itself been compromised (e.g. a home machine of an
employee), or a trojanized OpenSSH versions exist on your local Debian
mirror.
[...]
These attacks require wiretapping and traffic
manipulation capabilities.  

I'd be interested if you could expand on this - do you mean a
connection to the victim's LAN is necessary ?

I'd have thought ability to intercept WAN traffic was enough, but I
don't really know what I'm talking about :-).  And AIUI, traffic
manipulation is a standard technique for a skilled Bad Guy (injecting
packets, fiddling with packets, connection hijacking).  The sort of
skill level required to perform a sequence number attack would do,
wouldn't it ? 

If the edge networks are trustworthy, ...

Again it sounds like you're saying LAN access is needed.

I recognise what you're saying about the more likely scenarios though
(stolen access tokens, etc). [ IIRC, the www.apache.org crack was done
that way (http://www.apacheweek.com/issues/01-06-01#hack) ]

 Why do you think you are so special?

But someone's got to be the first to fall prey to each new technique -
why not Tim ?

Or are you saying the computational effort involved is as huge as,
say, a DES crack would be ?  (i.e. only national security services and
mobsters would have the resources ?)

Cheers
Nick Boyce
Bristol, UK
--
Yousa steala precious from meesa! - Jar-Jaromir

Re: Probable SSH Vulnerability

2003-06-13 Thread Nick Boyce

On Fri, 13 Jun 2003 17:52:21 -0400, Tim Peeler wrote:

On Fri, Jun 13, 2003 at 05:15:28PM -0400, David B Harris wrote:

On Fri, 13 Jun 2003 14:18:44 -0400
Tim Peeler [EMAIL PROTECTED] wrote:
In the last 4-5 days we have had 8 servers come under attack. We are
working frantically to keep ahead of these attacks. We have come to the
conclusion that the SSH in woody is likely vulnerable.
[...]
We have not had time
to analyze where the exploit occurs in sshd, but we are very confident
that this is the location of the exploit. We have begun upgrading to
a backport of the testing version of ssh which appears to be helping.

Could you provide your /etc/ssh/sshd_config, the version of your ssh
package, and the output from 'debsums ssh'? Thanks.

sshd_config for comprimized server attached, as well as the output of
debsums ssh

SSH Version: 3.4p1-1
[snip]

From your sshd_config :

Protocol 2,1

Um, aren't there known *unfixable* problems with the SSH1 protocol ?

http://www.cert.org/advisories/CA-2001-35.html
http://list.cobalt.com/pipermail/cobalt-security/2001-November/003857.html
http://groups.google.com/groups?q=ssh1+unfixablehl=enlr=ie=UTF-8oe=UTF-8selm=m1lsmv0faft.fsf%40syrinx.oankali.netrnum=1
http://groups.google.com/groups?q=ssh1+deprecatedhl=enlr=ie=UTF-8oe=UTF-8selm=Pine.LNX.4.10.10102101444180.22997-10%40mystery.acr.firnum=1

I may be wrong (not expert, etc) but I'm under the impression that
SSH1 is unfixably broken and should not now be used - certainly we
only have protocol 2 listed in all our server configs.

Having protocol 1 second in the list doesn't stop a client from
insisting on using it.

Tatu Ylonen says in the 4th reference above :

The whole CRC32 vulnerability is once again a
manifestation of certain fundamental problems
in the SSH1 key exchange and message authentication
mechanism. The SSH2 protocol was created to fix
these (and other) problems. The old SSH1 protocol
is deprecated, and people are strongly urged to
move to using the SSH2 protocol.

.. some cryptographers that I know have been
speculating whether it would be possible to
construct attack patterns that would get around
the CRC32 deattack mechanism entirely. The
original CRC32 attack works obtaining some known
plaintext-ciphertext pairs, and constructing a
special pattern that defeats the CRC32 that was
used as MAC in SSH1. The deattack code detects
the particular pattern used to defeat the CRC32
check. However, some people are speculating
that there may be other patterns (e.g.
involving more known plaintext-ciphertext pairs)
that would also compensate for CRC32 but would
not be detected by the deattack code.
I cannot confirm whether this is the case, but
I personally do not fully trust that the
deattack code will be able to prevent all
variations of the attack (even without the
bug in the deattack code). The real fix is to
move to using the SSH2 protocol.

My 2p, etc. You probably already know all this.

Do you *have* to have SSH1 enabled ?

(Sorry if this is all off-target)

Good luck
Nick Boyce
Bristol, UK

--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Probable SSH Vulnerability

2003-06-13 Thread Nick Boyce

On Fri, 13 Jun 2003 17:52:21 -0400, Tim Peeler wrote:

On Fri, Jun 13, 2003 at 05:15:28PM -0400, David B Harris wrote:

Could you provide your /etc/ssh/sshd_config, the version of your ssh
package, and the output from 'debsums ssh'? Thanks.

sshd_config for comprimized server attached, as well as the output of
debsums ssh

SSH Version: 3.4p1-1
[snip]

From your sshd_config :

Protocol 2,1

Um, aren't there known *unfixable* problems with the SSH1 protocol ?

I may be wrong (not expert, etc) but I'm under the impression that
SSH1 is unfixably broken and should not now be used - certainly we
only have protocol 2 listed in all our server configs.

Having protocol 1 second in the list doesn't stop a client from
insisting on using it.

Tatu Ylonen says in the 4th reference above :

My 2p, etc. You probably already know all this.

Do you *have* to have SSH1 enabled ?

(Sorry if this is all off-target)

Good luck
Nick Boyce
Bristol, UK

Re: Apt-get only security patches

2003-05-07 Thread Nick Boyce

On Wed, 7 May 2003 10:35:45 +0200, Rudolph van Graan wrote:

... For example on one of my stable machines,
the following happens when I do apt-get upgrade -u:

The following packages will be upgraded
  kdewallpapers mime-support
2 packages upgraded, 0 newly installed, 0 to remove and 0  not upgraded.
Need to get 0B/1030kB of archives. After unpacking 105kB will be freed.
Do you want to continue? [Y/n]

Obviously neither is of real security importance

The mime-support update *is* a security update !

See http://www.debian.org/security/2003/dsa-292

When a temporary file is to be used it is created insecurely

allows local users to overwrite arbitrary files via a symlink attack
on temporary files

So if you're the only user on the machine then I suppose you needn't
worry.

Cheers

Nick Boyce
Bristol, UK
--
There is no spoon.

Re: Snort exploit in wild.

2003-04-25 Thread Nick Boyce

On Fri, 25 Apr 2003 10:19:59 +0100, David Ramsden wrote:

Noticed on vil.mcafee.com that a proof of concept exploit for Snort to
exploit the vuln. found in v1.8 through to 1.9.1.
[...]
What's the status of a patch from Debian Security? No DSA yet either.
I know this has been brought up a few times already but now an exploit
exists in the wild.

David, you probably want to look at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=173254
which I submitted after a previous discussion on this list (December
2002) about problems with the Debian stable Snort package being out of
date.

The general consensus of opinion (including the Debian packager) was
that *nobody* should even consider using the V1.8.4 Snort package in
Woody - it's much too old, and has a number of security issues.

Most people's advice was to stop using the Debian package, and instead
download  compile the latest source from www.snort.org, and keep
tracking new releases from there - and get signature updates from
there as well.  This is what I do now.

Some people think Snort should actually be removed from the Debian
package collection, because it will always drift seriously out of date
over time, and because there's no easy way to incorporate up-to-date
signatures (rules) into Debian.

Cheers,

Nick Boyce
Bristol, UK
--
Boycott Amazon till they relent on the 1-click software patent
- http://www.gnu.org/philosophy/amazon.html

Kernel ptrace Hole - Fix For i386 ?

2003-04-14 Thread Nick Boyce

I'm wondering whether I've missed some announcement about a fixed
2.4.x package for this for i386 architecture.  We've had DSAs 270 and
276 providing the fixes for Mips and S390 systems, and lots of
discussion here about how to protect against the exploit *instead* of
having a fix ... and it's been over a couple of weeks now, and still
no i386 fix.

The fix is in vanilla kernel 2.4.20 as I understand it, and it sounds
like some people here are downloading that source for their Woody i386
systems.

Anyone know what the official plan is ?

Thanks

Nick Boyce
Bristol, UK
--
Spence's Admonition: 
Never stow away on a kamikaze plane.

Re: is this an attack ?

2003-03-29 Thread Nick Boyce

On 29 Mar 2003 10:46:02 -0300, danilo lujambio wrote:

I have a ftp server secured with the directives that I found in general
docs. Yesterday my server was down at 19:30 aprox , the only suspicious
track that I found is : 

18:59:06 web wu-ftpd[10527]: connect from 200.158.144.201
Mar 28 18:59:07 web wu-ftpd[10527]: USER anonymous
Mar 28 18:59:07 web wu-ftpd[10527]: PASS [EMAIL PROTECTED]
Mar 28 18:59:07 web wu-ftpd[10527]: USER anonymous
Mar 28 18:59:07 web wu-ftpd[10527]: PASS [EMAIL PROTECTED]
Mar 28 18:59:08 web wu-ftpd[10527]: TYPE Image
Mar 28 18:59:08 web wu-ftpd[10527]: STRU File
Mar 28 18:59:08 web wu-ftpd[10527]: TYPE Image
Mar 28 18:59:08 web wu-ftpd[10527]: STRU File
Mar 28 18:59:09 web wu-ftpd[10527]: MODE Stream
Mar 28 18:59:09 web wu-ftpd[10527]: REST 0
Mar 28 18:59:09 web wu-ftpd[10527]: REST 1
Mar 28 18:59:09 web wu-ftpd[10527]: MODE Stream
Mar 28 18:59:09 web wu-ftpd[10527]: REST 0
Mar 28 18:59:09 web wu-ftpd[10527]: REST 1
Mar 28 18:59:10 web wu-ftpd[10527]: SYST
Mar 28 18:59:10 web wu-ftpd[10527]: PASV
Mar 28 18:59:10 web wu-ftpd[10527]: SYST
Mar 28 18:59:10 web wu-ftpd[10527]: PASV
Mar 28 18:59:14 web wu-ftpd[10527]: TYPE ASCII
Mar 28 18:59:15 web wu-ftpd[10527]: LIST /
Mar 28 18:59:16 web wu-ftpd[10527]: CWD /bin
Mar 28 18:59:16 web wu-ftpd[10527]: PASV
Mar 28 18:59:16 web wu-ftpd[10527]: TYPE Image
Mar 28 18:59:16 web wu-ftpd[10527]: CWD /bin
Mar 28 18:59:16 web wu-ftpd[10527]: PASV
Mar 28 18:59:16 web wu-ftpd[10527]: TYPE Image
Mar 28 18:59:17 web wu-ftpd[10527]: ALLO 104154
Mar 28 18:59:17 web wu-ftpd[10527]: REST 0
Mar 28 18:59:17 web wu-ftpd[10527]: STOR 582.258
Mar 28 18:59:17 web wu-ftpd[10527]: ALLO 104154
Mar 28 18:59:17 web wu-ftpd[10527]: REST 0
Mar 28 18:59:17 web wu-ftpd[10527]: STOR 582.258
Mar 28 18:59:17 web wu-ftpd[10527]: ALLO 104154
Mar 28 18:59:17 web wu-ftpd[10527]: REST 0
Mar 28 18:59:17 web wu-ftpd[10527]: STOR 582.258
[snip]

Hmm.  It's worth pointing out that some GUI FTP clients attempt to
avoid server-enforced idle timeouts of the control connection by
issuing random no-op commands at regular intervals to fool the
server into thinking meaningful activity is taking place - some of the
above looks like that.

However, the timestamps are closer together than is warranted for
this, and I'd be as suspicious as you about the ALLO and STOR
commands - they don't look like no-op commands to me.

Sorry I can't say anything more helpful.

Nick Boyce
Bristol, UK
--
Remember - friends don't send friends HTML e-mail


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: is this an attack ?

2003-03-29 Thread Nick Boyce

On 29 Mar 2003 10:46:02 -0300, danilo lujambio wrote:

I have a ftp server secured with the directives that I found in general
docs. Yesterday my server was down at 19:30 aprox , the only suspicious
track that I found is : 

18:59:06 web wu-ftpd[10527]: connect from 200.158.144.201
Mar 28 18:59:07 web wu-ftpd[10527]: USER anonymous
Mar 28 18:59:07 web wu-ftpd[10527]: PASS [EMAIL PROTECTED]
Mar 28 18:59:07 web wu-ftpd[10527]: USER anonymous
Mar 28 18:59:07 web wu-ftpd[10527]: PASS [EMAIL PROTECTED]
Mar 28 18:59:08 web wu-ftpd[10527]: TYPE Image
Mar 28 18:59:08 web wu-ftpd[10527]: STRU File
Mar 28 18:59:08 web wu-ftpd[10527]: TYPE Image
Mar 28 18:59:08 web wu-ftpd[10527]: STRU File
Mar 28 18:59:09 web wu-ftpd[10527]: MODE Stream
Mar 28 18:59:09 web wu-ftpd[10527]: REST 0
Mar 28 18:59:09 web wu-ftpd[10527]: REST 1
Mar 28 18:59:09 web wu-ftpd[10527]: MODE Stream
Mar 28 18:59:09 web wu-ftpd[10527]: REST 0
Mar 28 18:59:09 web wu-ftpd[10527]: REST 1
Mar 28 18:59:10 web wu-ftpd[10527]: SYST
Mar 28 18:59:10 web wu-ftpd[10527]: PASV
Mar 28 18:59:10 web wu-ftpd[10527]: SYST
Mar 28 18:59:10 web wu-ftpd[10527]: PASV
Mar 28 18:59:14 web wu-ftpd[10527]: TYPE ASCII
Mar 28 18:59:15 web wu-ftpd[10527]: LIST /
Mar 28 18:59:16 web wu-ftpd[10527]: CWD /bin
Mar 28 18:59:16 web wu-ftpd[10527]: PASV
Mar 28 18:59:16 web wu-ftpd[10527]: TYPE Image
Mar 28 18:59:16 web wu-ftpd[10527]: CWD /bin
Mar 28 18:59:16 web wu-ftpd[10527]: PASV
Mar 28 18:59:16 web wu-ftpd[10527]: TYPE Image
Mar 28 18:59:17 web wu-ftpd[10527]: ALLO 104154
Mar 28 18:59:17 web wu-ftpd[10527]: REST 0
Mar 28 18:59:17 web wu-ftpd[10527]: STOR 582.258
Mar 28 18:59:17 web wu-ftpd[10527]: ALLO 104154
Mar 28 18:59:17 web wu-ftpd[10527]: REST 0
Mar 28 18:59:17 web wu-ftpd[10527]: STOR 582.258
Mar 28 18:59:17 web wu-ftpd[10527]: ALLO 104154
Mar 28 18:59:17 web wu-ftpd[10527]: REST 0
Mar 28 18:59:17 web wu-ftpd[10527]: STOR 582.258
[snip]

Hmm.  It's worth pointing out that some GUI FTP clients attempt to
avoid server-enforced idle timeouts of the control connection by
issuing random no-op commands at regular intervals to fool the
server into thinking meaningful activity is taking place - some of the
above looks like that.

However, the timestamps are closer together than is warranted for
this, and I'd be as suspicious as you about the ALLO and STOR
commands - they don't look like no-op commands to me.

Sorry I can't say anything more helpful.

Nick Boyce
Bristol, UK
--
Remember - friends don't send friends HTML e-mail

Re: [SECURITY] [DSA 265-1] -- BAD SIGNATURE !?

2003-03-23 Thread Nick Boyce

On Saturday 22 Mar 2003 6:36 am, Martin Schulze wrote:

Nick Boyce wrote :

I get a bad signature reported by Kmail on this announcement.
Saving the message out to a text file and verifying manually also
fails :

Ditch KMail, it is a permanent source of problems when it comes to
digital signatures.

Jeez .. that's disturbing to hear ..

Also read http://www.debian.org/security/faq#signature

OK - thanks for the pointer - I just read that page and am now
enlightened :)

1) The following is good to know :

The debian-security-announce list has a filter that
only allows messages with a correct signature from
one of the security team members to be posted.

2) but this bit is not :

Most likely some piece of mail software on your
end ... breaks the signature.
Known culprits are fetchmail (with the mimedecode
option enabled), formail (from procmail 3.14 only)
and evolution.

(and Kmail it seems)

It seems to me we have a biggish problem with some major mail clients
here - we should not just live with this situation.

I'm particularly bemused by the way Kmail handles your signatures fine
for me, for all other DSA's from you that I've ever received - and also
handles other people's signatures without apparent problem - and yet it
screwed this one up.

An even more disturbing thought is that in contrast to rejecting
signatures that are in fact good, Kmail may validate signatures that
are in fact bad ...

Feel free to fetch the message from the list archives on the
web and verify that one instead of the local copy.

I did that, and, as you suggest, it verifies ok; I selected all text on
http://lists.debian.org/debian-security-announce/debian-security-announce-2003/msg00048.html

and saved it to a file using Kate, and manually ran gpg :

[EMAIL PROTECTED]:~$ gpg --verify DSA-265-1-3.txt
gpg: Signature made Fri 21 Mar 2003 14:01:16 GMT using DSA key ID
801EA932
gpg: Good signature from Martin Schulze [EMAIL PROTECTED]
gpg: aka Martin Schulze [EMAIL PROTECTED]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
Primary key fingerprint: B53F E57B D0C1 F689 FCE2 5623 5B9A A5F8 801E
A932

Thanks for calming me down again :-)

Cheers
Nick Boyce
Bristol, UK

Re: [SECURITY] [DSA 265-1] -- BAD SIGNATURE !?

2003-03-21 Thread Nick Boyce

On Friday 21 Mar 2003 2:01 pm, Martin Schulze wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 -
- Debian Security Advisory DSA 265-1
 [EMAIL PROTECTED] http://www.debian.org/security/  
   Martin Schulze March 21st, 2003   
 http://www.debian.org/security/faq
 -
[snip]

I get a bad signature reported by Kmail on this announcement.  Saving 
the message out to a text file and verifying manually also fails :

[EMAIL PROTECTED]:~$ gpg --verify DSA-265-1.txt
gpg: Signature made Fri 21 Mar 2003 14:01:16 GMT using DSA key ID 
801EA932
gpg: BAD signature from Martin Schulze [EMAIL PROTECTED]


The last message from Joey that I saw was DSA 264-1, on 19th.March, 
signed using the same key, which validated OK.

Anyone else ?

Nick Boyce
Bristol, UK


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: [SECURITY] [DSA 265-1] -- BAD SIGNATURE !?

2003-03-21 Thread Nick Boyce

On Friday 21 Mar 2003 2:01 pm, Martin Schulze wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 -
- Debian Security Advisory DSA 265-1
 [EMAIL PROTECTED] http://www.debian.org/security/  
   Martin Schulze March 21st, 2003   
 http://www.debian.org/security/faq
 -
[snip]

I get a bad signature reported by Kmail on this announcement.  Saving 
the message out to a text file and verifying manually also fails :

[EMAIL PROTECTED]:~$ gpg --verify DSA-265-1.txt
gpg: Signature made Fri 21 Mar 2003 14:01:16 GMT using DSA key ID 
801EA932
gpg: BAD signature from Martin Schulze [EMAIL PROTECTED]


The last message from Joey that I saw was DSA 264-1, on 19th.March, 
signed using the same key, which validated OK.

Anyone else ?

Nick Boyce
Bristol, UK

Re: FTP-SSL

2002-12-20 Thread Nick Boyce

On Wed, 18 Dec 2002 10:53:45 +0100, [EMAIL PROTECTED] wrote:

and I need some ftp-ssl client for windows 2000, is there anyone free ?

I use FileZilla (http://filezilla.sourceforge.net), which is free and
GPL'd, and lean and fast, and has a fairly nice interface.  It does
FTP, SFTP over SSH2, and two kinds of FTP over SSL (implicit
encryption and explicit encryption). I've used the FTP mode (works
fine), and the SFTP mode to a Debian system running OpenSSH - worked
fine for me and the SFTP user interface it gave me was just like a
regular FTP client session (I couldn't tell the difference).

[I've never even seen an FTP-SSL server, never mind tested against one
- does anyone know any pros  cons versus SFTP ? ]

FileZilla also interfaces with PuTTY if installed, to make use of
PuTTY's keystore for authenticating against the SFTP server - sounds
useful but I didn't try it yet.

As far as the argument about SCP vs SFTP is concerned, I wouldn't know
myself, but PuTTY's helpfile says this :

 cut ===
If you have an SSH 2 server, you might prefer PSFTP ... for
interactive use. PSFTP does not in general work with SSH 1 servers,
however.

[There is a security problem with the way SCP connections handle
wildcard filenames that is due to] a fundamental insecurity in the
old-style SCP protocol: the client sends the wildcard string (*.c) to
the server, and the server sends back a sequence of file names that
match the wildcard pattern. However, there is nothing to stop the
server sending back a different pattern and writing over one of your
other files: if you request *.c, the server might send back the file
name AUTOEXEC.BAT and install a virus for you. Since the wildcard
matching rules are decided by the server, the client cannot reliably
verify that the filenames sent back match the pattern.

PSCP will attempt to use the newer SFTP protocol (part of SSH 2) where
possible, which does not suffer from this security flaw. If you are
talking to an SSH 2 server which supports SFTP, you will never see
this warning.

If you really need to use a server-side wildcard with an SSH 1 server,
you can use the -unsafe command line option with PSCP:

 [example snipped]

This will suppress the warning message and the file transfer will
happen. However, you should be aware that by using this option you are
giving the server the ability to write to any file in the target
directory, so you should only use this option if you trust the server
administrator not to be malicious (and not to let the server machine
be cracked by malicious people).

[...]

PSFTP, the PuTTY SFTP client, is a tool for transferring files
securely between computers using an SSH connection.

PSFTP differs from PSCP in the following ways:

PSCP should work on virtually every SSH server. PSFTP uses the new
SFTP protocol, which is a feature of SSH 2 only. (PSCP will also use
this protocol if it can, but there is an SSH 1 equivalent it can fall
back to if it cannot.)
 cut ===

Hope some of that helps :)

Nick Boyce
Bristol, UK
--
Special Relativity: The person in the other queue thinks yours is
moving faster.

Re: Need an advise about isolating a host in the DMZ

2002-12-20 Thread Nick Boyce

On Wed, 18 Dec 2002 14:19:52 +0200 (IST), [EMAIL PROTECTED] wrote:

I'm thinking about using qmail as the smtp(only have access from the mail
relay server)/pop3 server (from what I've read this is a very secure
software). any suggestions about what ftp server should I run (is proftpd
secure enough)?

I've switched to vsftpd (there's a deb in Woody), which works fine and
is said to be written very securely, though it's not as full featured
as others.

(I haven't tried any others, apart from the stock Debian ftpd - there
have been so many security problems with daemons based on the old BSD
codebase that it seems worth switching to one that's completely new
and unrelated.)

Nick Boyce
Bristol, UK
--
... the fundamental design flaws are completely hidden by the
superficial design flaws.
Douglas Adams(1952 - 2001): So Long and Thanks For All The Fish.

Bug #173254 Submitted: Snort In Stable Unusable

2002-12-16 Thread Nick Boyce

Further to the discussion I started here on 6th.Dec.2002 about the
problem of the stable Snort packages being out-of-date, with the
subject Updating Snort Signatures In Stable ?
(http://lists.debian.org/debian-security/2002/debian-security-200212/msg00063.html)
FYI, I have now submitted a severity=minor bug, #173254, suggesting
the packages.d.o web-page for Snort be annotated to warn new users
that the package is deprecated in favour of V1.9.0 from www.snort.org.

The maintainer, Sander Smeenk, has already replied, agreeing with most
points that people raised, but advising that he doesn't believe he has
the power to have such a warning added to this page, and that perhaps
the Debian webmaster should be asked to make the amendment.
(See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=173254).

I assume a Debian developer would be needed to make such a request to
the webmaster.

Actually, I wonder whether the package pages _can_ be annotated like
this, if they're automatically generated from the package data - but I
guess it's worth asking the webmaster. Maybe there's room for at least
a pointer to a page elsewhere holding the warning.

Sander's preferred option would be to remove the Snort package
altogether in these circumstances.  What would be quicker : remove the
package, or add the warning to the web-page ?   I guess we ought to do
*something*.

Comments ?

Nick Boyce
Bristol, UK
--
Special Relativity: The person in the other queue thinks yours is
moving faster.

Re: Updating Snort Signatures In Stable ?

2002-12-10 Thread Nick Boyce

On Tue, 10 Dec 2002 13:52:06 -0500, Matt Zimmerman wrote:

[re: installing the snort binary from unstable]

... And I prefer not to
install unstable glibc on my stable systems.

Yeah - I thought there was a big problem with installing any unstable
*binary* on a stable box, for exactly that reason.

I too don't want the unstable glibc - surely it means you have to
replace just about every other binary on the system ?

Nick Boyce
Bristol, UK
--
Petreley's First Law of Computer Journalism: 
No technology exists until Microsoft invents it.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Updating Snort Signatures In Stable ?

2002-12-08 Thread Nick Boyce

On Sat, 7 Dec 2002 13:51:11 +0100, Javier Fernández-Sanguino Peña
wrote:

On Sat, Dec 07, 2002 at 02:46:01AM +, Nick Boyce wrote:
 I'd suggest maybe a note about V1.8.4 being useless should be added
 to http://packages.debian.org/stable/net/snort.html, along with some
 advice about getting signature updates (i.e. roll your own).

   Why not file a bug?

Erm, ok - is that the right way to get a docs amendment done ?
(Rather than, say, emailing the package maintainer, who I see is
Robert van der Meulen [EMAIL PROTECTED]) ?

If I submit a bug (never done that before) for this, would you say it
should have severity important, or minor ?  (It doesn't seem like
a normal bug :-)

Thanks,
Nick Boyce
Bristol, UK
--
Ok spammer, I'll 'just hit delete'. You can be 'Delete'.
 --  Ron SuperTroll Ritzman, NANAE


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Updating Snort Signatures In Stable ?

2002-12-08 Thread Nick Boyce

On Sat, 7 Dec 2002 13:51:11 +0100, Javier Fernández-Sanguino Peña
wrote:

On Sat, Dec 07, 2002 at 02:46:01AM +, Nick Boyce wrote:
 I'd suggest maybe a note about V1.8.4 being useless should be added
 to http://packages.debian.org/stable/net/snort.html, along with some
 advice about getting signature updates (i.e. roll your own).

   Why not file a bug?

Erm, ok - is that the right way to get a docs amendment done ?
(Rather than, say, emailing the package maintainer, who I see is
Robert van der Meulen [EMAIL PROTECTED]) ?

If I submit a bug (never done that before) for this, would you say it
should have severity important, or minor ?  (It doesn't seem like
a normal bug :-)

Thanks,
Nick Boyce
Bristol, UK
--
Ok spammer, I'll 'just hit delete'. You can be 'Delete'.
 --  Ron SuperTroll Ritzman, NANAE

Re: Updating Snort Signatures In Stable ?

2002-12-06 Thread Nick Boyce

On Fri, 06 Dec 2002 04:18:52 +, I wrote:

I've been running Snort for a month or so now on a Woody box at work,
and am now wondering whether the Debian Project (or packager) has a
Plan for providing signature file updates to users of the stable
distribution.

Well thanks for the answers folks - it seems clear (especially after
checking http://www.snort.org/dl/rules/, which says If you are using
a version before 1.9.x, please upgrade) that I should stop using the
Debian stable V1.8.4 package and switch to hand-built V1.9.0 made from
source - and I'll gladly grab Kristof's signature update script and
adapt to my needs (thanks for that).

[I hope my current MySQL and Acidlab backend works with the later
Snort - I guess I'm about to find out ..]

I'd suggest maybe a note about V1.8.4 being useless should be added
to http://packages.debian.org/stable/net/snort.html, along with some
advice about getting signature updates (i.e. roll your own).

IIRC important new versions of existing packages are allowed into
point releases, so maybe Woody's main Snort engine binary packages can
be updated when 3.0r1 happens.

And I still think it'd be nice if we could find a way to package up
and push out stable signature updates - but I can see why that would
be difficult to set policy for.

Cheers,

Nick Boyce
Bristol, UK
--
... the fundamental design flaws are completely hidden by the
superficial design flaws.
Douglas Adams(1952 - 2001): So Long and Thanks For All The Fish.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Updating Snort Signatures In Stable ?

2002-12-06 Thread Nick Boyce

On Fri, 06 Dec 2002 04:18:52 +, I wrote:

I've been running Snort for a month or so now on a Woody box at work,
and am now wondering whether the Debian Project (or packager) has a
Plan for providing signature file updates to users of the stable
distribution.

Well thanks for the answers folks - it seems clear (especially after
checking http://www.snort.org/dl/rules/, which says If you are using
a version before 1.9.x, please upgrade) that I should stop using the
Debian stable V1.8.4 package and switch to hand-built V1.9.0 made from
source - and I'll gladly grab Kristof's signature update script and
adapt to my needs (thanks for that).

[I hope my current MySQL and Acidlab backend works with the later
Snort - I guess I'm about to find out ..]

I'd suggest maybe a note about V1.8.4 being useless should be added
to http://packages.debian.org/stable/net/snort.html, along with some
advice about getting signature updates (i.e. roll your own).

IIRC important new versions of existing packages are allowed into
point releases, so maybe Woody's main Snort engine binary packages can
be updated when 3.0r1 happens.

And I still think it'd be nice if we could find a way to package up
and push out stable signature updates - but I can see why that would
be difficult to set policy for.

Cheers,

Nick Boyce
Bristol, UK
--
... the fundamental design flaws are completely hidden by the
superficial design flaws.
Douglas Adams(1952 - 2001): So Long and Thanks For All The Fish.

Updating Snort Signatures In Stable ?

2002-12-05 Thread Nick Boyce

I've been running Snort for a month or so now on a Woody box at work,
and am now wondering whether the Debian Project (or packager) has a
Plan for providing signature file updates to users of the stable
distribution.

The snort-rules-default package available in stable never gets updated
- nor would we normally expect it to unless a security vulnerability
arises - but obviously IDS signatures must be kept up to date on a
*timely* basis, just like antivirus package signatures, for the
package to be fully effective.

I don't intend any criticism, but do wonder what we're expected to do
about this - download fresh signatures straight from www.snort.org ?

If so, are there any special steps required to integrate such a
download into our Debian Woody system ?

Alternatively, I note there are later signature packages in testing
and unstable - can we use those on a Woody system ?

I searched the debian-security archive but didn't hit any items
discussing this, so maybe it's a dumb question - sorry, I'm a newb
here.

Thanks for _any_ comments at all.

Nick Boyce
Bristol, UK
--
Stenderup's Law: The sooner you fall behind, the more time you will have to catch up.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Updating Snort Signatures In Stable ?

2002-12-05 Thread Nick Boyce

I've been running Snort for a month or so now on a Woody box at work,
and am now wondering whether the Debian Project (or packager) has a
Plan for providing signature file updates to users of the stable
distribution.

The snort-rules-default package available in stable never gets updated
- nor would we normally expect it to unless a security vulnerability
arises - but obviously IDS signatures must be kept up to date on a
*timely* basis, just like antivirus package signatures, for the
package to be fully effective.

I don't intend any criticism, but do wonder what we're expected to do
about this - download fresh signatures straight from www.snort.org ?

If so, are there any special steps required to integrate such a
download into our Debian Woody system ?

Alternatively, I note there are later signature packages in testing
and unstable - can we use those on a Woody system ?

I searched the debian-security archive but didn't hit any items
discussing this, so maybe it's a dumb question - sorry, I'm a newb
here.

Thanks for _any_ comments at all.

Nick Boyce
Bristol, UK
--
Stenderup's Law: The sooner you fall behind, the more time you will have to 
catch up.

Re: Permissions Required On hosts.allow ?

2002-09-01 Thread Nick Boyce

On Fri, 30 Aug 2002 18:16:45 -0700, Jamie Heilman wrote:

 .. There is no legitimate reason to jump through all these
hoops just to hide your tcp wrappers configuration from your local
users.  

I come to the Land Of Unix from mainframes, where I used to earn my
crust.  The mainframes had a tight security lockdown from out of the
box (or truck, as the case usually was of course :).  I'm used to a
security stance of
access-to-anything-is-denied-unless-explicitly-permitted, which I
feel is absolutely the right approach.  I'm a bit taken aback by the
idea of allowing everybody to see everything by default (mask 022 ? -
has to be the wrong thing ..)  I'm constantly looking for ways of
achieving the same discretionary access control stance in my personal
Unix box.  Humour me ?

If the requirements for your host dictate minimal access rights 
use an access control system thats been designed to achieve it

I'd be very interested to hear about any such options in the Linux
world.  AFAIK, Linux ACL facilities are still experimental
(http://packages.debian.org/testing/admin/kernel-patch-acl.html)

Thanks for your commentary, which was welcome.

Nick Boyce
Bristol, UK
--
The last ~700 Kalahari Bushmen are being evicted from their
ancestral homeland by the Botswanan government *now*, so that
De Beers  Anglo-American can prospect for diamonds.  The
Bushmen are having their water supply cut off ...
[11.Jan.2002]

Re: Permissions Required On hosts.allow ?

2002-09-01 Thread Nick Boyce

On Fri, 30 Aug 2002 07:38:45 -0400, Edward Guldemond wrote:

On Thu, Aug 29, 2002 at 02:51:14AM +0100, Nick Boyce wrote:
 
 I decided to start locking down permissions on sensitive files on a
 recently installed Woody box, and discovered that when I changed the
 permissions on hosts.allow (and hosts.deny) to 640 then I could no
 longer Telnet into the box 
[...]

Maybe this is a lame question in response, but why would users being able
to see hosts.allow and hosts.deny constitute a security hole?  

It's a not a security _hole_ as such - the point is just that's it's a
bad idea to give an attacker _any_ help whatsoever.  We don't want
them to be able to learn which other machines on the network are
trusted in particular ways ... do we ?

The Wily Hacker has to start with the research phase - general
reconnaisance - and we want to obstruct them wherever possible.

Cheers,
Nick Boyce
Bristol, UK
--
Bombeck's Rule of Medicine: Never go to a doctor whose office plants have died.

Re: Permissions Required On hosts.allow ?

2002-08-29 Thread Nick Boyce

On Wed, 28 Aug 2002 21:03:53 -0700, Jamie Heilman wrote:

 Can I change this around a bit to achieve my goal - maybe make a new
 group called foo (say) and give that gid to in.telnetd and
 hosts.allow ... ?

Obscuring your libwrap/tcpd configuration from your local users, at
the expense of allowing services to run as seperate, non-privileged
users is a bad idea.  

Well if that's what the price is then I agree with you.  But I can't
see where we'd lose if all that the group foo membership gives the
daemons is tcp wrappers config file read access.

It does occur to me that maybe in.telnetd (say) _depends_ on having
its group telnetd membership for some purpose though ..

Cheers,

Nick Boyce
Bristol, UK
--
Microsoft may provide updates that will be automatically downloaded onto 
your computer. These updates may disable your ability to copy and/or play
content and use other software on your computer.
-- http://bsdvault.net/article.php?sid=527mode=order=0

Re: Permissions Required On hosts.allow ?

2002-08-29 Thread Nick Boyce

On Thu, 29 Aug 2002 08:37:15 -0600 (MDT), Joe Moore wrote:

Another option would be to create a group, for example called tcpwrap.
Add
tcpwrap:x:150:telnetd, sshd, irc, identd
(This list is based on the users in /etc/passwd which appear to be for
services that would benefit from tcpwrap.  Adjust as appropriate.)

Set /etc/hosts.allow to mod 0640 and ownership root:tcpwrap

When tcpd is running as UID telnetd, it will also have group equivalence to
GID tcpwrap, so it will be able to read /etc/hosts.allow

Yep - that's just the sort of thing I had in mind - I can't see a
problem with it if all the new GID does is grant read access to the
tcp wrappers config files.  [ I just realised one more ingredient
required is to make the relevant service daemons sgid tcpwrap as well
as members of it. ]

But I realise this stuff is tricky, and there may be some unforseen
consequence that only a thorough knowledge of the source code (which I
don't have) can elicit - that's why I sought comments :)

I'm still not sure about it.
Cheers,

Nick Boyce
Bristol, UK
--
Ok spammer, I'll 'just hit delete'. You can be 'Delete'.
 --  Ron SuperTroll Ritzman, NANAE

Permissions Required On hosts.allow ?

2002-08-28 Thread Nick Boyce

[hope this isn't too lame a question for this list]

I decided to start locking down permissions on sensitive files on a
recently installed Woody box, and discovered that when I changed the
permissions on hosts.allow (and hosts.deny) to 640 then I could no
longer Telnet into the box from the permitted IP address (never mind
denied addresses).  /var/log/daemon.log had messages in it to the
effect that tcpd couldn't read hosts.allow, so was denying the
connection.

So I've opened perms up to 644 again, but this seems the wrong thing
to do.  I realise I was only gaining a minor layer of
security-thru-obscurity, but every little helps - surely we don't want
this file to be world-readable ?

I note from inetd.conf that in.telnetd runs as uid.gid
telnetd.telnetd, whereas hosts.allow has uid.gid root.root, which I
guess is the cause of this.  Can I change this around a bit to achieve
my goal - maybe make a new group called foo (say) and give that gid
to in.telnetd and hosts.allow ... ?

[ BTW: I *do* use SSH for all network access - I only have 127.0.0.1
listed for in.telnetd in hosts.allow, to allow myself to telnet 0 -
sometimes I like to start a new session like that, and ssh takes so
much longer to start up a session ... ]

TIA,
Nick Boyce
Bristol, UK
--
The universe is entering maintenance mode in 2 minutes. Please logout.
  -- Your administrator

85 matches

Mail list logo