Re: Light weight IDSes and then some

[Alec Berryman]

George P Boutwell on 2005-07-14 18:02:40 -0500:

> > > 2) Apache & or cgi-bins I use, where the cause of my closest to being
> > > compromised situations.  If I set-up Apache, PHP, cgis, etc in a
> > > chroot jail, how can I still provide and /~username/ type set-up, as I
> > > have at least 2 situations where I rely heavily on that?  As near as I
> > > can tell this is not covered in any of the Apache chroot information
> > > I've read.
> > I don't really see the problem with /~username/ in a chroot
> > environment. You can
> > loopback mount if you need those homes somewhere else as well.
> 
> Well.. Currently if I add a user, say user1...  He gest an public_html
> directory added to his /home/user1 directory.  If he set-up an index
> file of some kind in that directory the url http://myserver/~user1/
> gives him that index file...  How could I still provide ~/public_html
> directory in users 'home' and still have Apache serve it up from a
> chroot?

OpenBSD places all of the user's public_html directories under the
Apache chroot.  I've found it no hassle to put a symlink in the user's
directory, but then again I wasn't doing quotas.


pgptklGpWdWS9.pgp
Description: PGP signature

Re: Light weight IDSes and then some

[Brian Bilbrey]

George P Boutwell wrote:
...

It looks as though you've gotten at least one other reply, but I've not 
seen it/them (yet)



3) I'd like to provide some limited SFTP (SSH FTP) mechanisms for
select individuals, for these I would really like to do away with the
shell, but I haven't found away, how can I provide an shell-less SFTP
or severely restricted SFTP service for these people?


To provide the type of access you're talking about above, I use scponly

http://www.sublimation.org/scponly/

version 4.1 available on the site, 4.0.2 is in unstable.

Chrootable, easily configured for multiple users, quite handy. The man 
pages and README are required if you want it setup right, though.


best,

.brian

--
Brian Bilbrey : http://www.orbdesigns.com/
"Kirk to Enterprise -- beam down yeoman Rand and a six-pack."


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

Re: New squid packages 2.4.6-2woody9 restarts very often.

[Woon Wai Keen @ doubleukay.com]

On 15/07/2005 3:33 AM, Luigi Gangitano wrote:


but didn't succeed. Can somebody please provide some more informations
like

- configuration file
- type of DNS used (BIND, dnscache, etc)
- a core file (if found)

I'm preparing a debug-enabled version to help extract more details, I'll
send to whom may be interested in helping with debug.


Hi, I'm also having this squid problem.

I'm using
- squid in transparent proxy mode
- mostly stock configuration file, with two cache_dirs and transparent 
proxy options

- pdnsd caching DNS server

I'll be happy to help in debugging.

--
Regards,
wK (www.doubleukay.com)


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Light weight IDSes and then some

[George P Boutwell]

On 7/14/05, DI Peter Burgstaller <[EMAIL PROTECTED]> wrote:
> I'm using AIDE and am very happy with it.

Thanks I'll look into it.

> > 2) Apache & or cgi-bins I use, where the cause of my closest to being
> > compromised situations.  If I set-up Apache, PHP, cgis, etc in a
> > chroot jail, how can I still provide and /~username/ type set-up, as I
> > have at least 2 situations where I rely heavily on that?  As near as I
> > can tell this is not covered in any of the Apache chroot information
> > I've read.
> I don't really see the problem with /~username/ in a chroot
> environment. You can
> loopback mount if you need those homes somewhere else as well.

Well.. Currently if I add a user, say user1...  He gest an public_html
directory added to his /home/user1 directory.  If he set-up an index
file of some kind in that directory the url http://myserver/~user1/
gives him that index file...  How could I still provide ~/public_html
directory in users 'home' and still have Apache serve it up from a
chroot?


> > 3) I'd like to provide some limited SFTP (SSH FTP) mechanisms for
> > select individuals, for these I would really like to do away with the
> > shell, but I haven't found away, how can I provide an shell-less SFTP
> > or severely restricted SFTP service for these people?
> 
> If you already have apache on that machine, why not run webdav on
> apache-ssl and you won't need shell accounts

Hmm... I'll have to think about that...  However SSH is the main way
that I admin my machine (it's basically headless - my woody one has
been so reliable :) ) and it has some really nice FTP like tools that
support it (like FileZilla)

Thanks Peter for your comment, recommendations, etc.

-- 
George

Light weight IDSes and then some

[George P Boutwell]

Hello,

  I currently have a Woody NAT/Firewall machine that provides internet
to my home LAN.  In addition to that it provides Web proxy and Web
serving (mainly for a few pages for my family and friends).  It's been
running nicely for several years now.  Last year I had 2 cases where I
had near misses on being compromised.  I've gotten a new box and I'm
planning and preparing it to replace my existing Woody with Sarge on
this new box.  I'm trying to plan a somewhat hardened and more secure
installation this time to better handle the possible compromises I
nearly came to face last year.  I have some questions and help that I
need.

Goal:  To provide an Internet Connection NAT/Firewall, with (Squid)
Transparent Proxy, DNS Caching, Apache, and SSH. (ie replace and may
be enhance a little the current box(

Questions:

  I'm going to follow the Debian How-To on Securing Debian, which so
far has been extermely helpful in seeing some thing I can do when I
get that 'oh my, I've been compromised' feeling, how do I verify it
ain't so.

1) What are some projects/software for light IDS, specifically file
checksome/change control.  I plan on doing the MD5 checksum floppy as
described in the Secuirng How-To, but then I want an software that
does that and e-mails my admin user whenever checksums and permissions
change.

2) Apache & or cgi-bins I use, where the cause of my closest to being
compromised situations.  If I set-up Apache, PHP, cgis, etc in a
chroot jail, how can I still provide and /~username/ type set-up, as I
have at least 2 situations where I rely heavily on that?  As near as I
can tell this is not covered in any of the Apache chroot information
I've read.

3) I'd like to provide some limited SFTP (SSH FTP) mechanisms for
select individuals, for these I would really like to do away with the
shell, but I haven't found away, how can I provide an shell-less SFTP
or severely restricted SFTP service for these people?

Any help or suggestions, especially software or packages that I should
research during my planning would be greatly appreciated.

Thanks,
-- 
George

Re: Timeliness of Debian Security Announceness? (DSA 756-1 Squirrelmail)

[Stefan Fritsch]

On Thursday 14 July 2005 22:03, Fredrik "Demonen" Vold wrote:
> I think it's possible for a script to list all installed packages,
> then check each of them against the bug report system to see if the
> installed version has a security bug filed against it.
>
> Maybe if some autmated system on the server would generate a
> "Security.gz" or something else similar to the package list for
> apt? I really don't know enough of the bug tracking system to know
> if this is possible, but it opens up alot of possibilities if it
> is.

There is a page listing all security bugs:
http://qa.debian.org/bts-security.html

And a quick hack to extract only the bugs for installed packages is at 
http://www.sfritsch.de/debian/list-bts-security (uses 
apt-show-versions and libwww-perl). Probably it would be nice to add 
some functionality to only show the differences from the last run...


Cheers,
Stefan


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

Re: Timeliness of Debian Security Announceness? (DSA 756-1 Squirrelmail)

[Jan Lühr]

Greetings,

Am Donnerstag, 14. Juli 2005 17:40 schrieb Herwig Wittmann:
> Hi!
>
> I am trying to understand if my organization can rely on the debian
> security announcement mailing list as only source of security alerts in
> the future.
>
> This would be very convenient- but the delay that seems to have passed
> between the original squirrelmail security announcement and the time I
> received the alert via [EMAIL PROTECTED] is worrying:

If you've been following debian for at least a couple of months, you got to 
know, that this issue was fixed rather fast.
However, my - one and only - advice in this case is: Don't use debian 
packages, if this is vital for you!

Keep smiling
yanosz


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

Re: Timeliness of Debian Security Announceness? (DSA 756-1 Squirrelmail)

[Fredrik \"Demonen\" Vold]

> More important is to know if you are vulnerable. 
Yeah.  I agree.

I purpose a slight addition to dpkg:

dpkg-secure

I think it's possible for a script to list all installed packages,
then check each of them against the bug report system to see if the
installed version has a security bug filed against it.

Maybe if some autmated system on the server would generate a
"Security.gz" or something else similar to the package list for apt?
I really don't know enough of the bug tracking system to know if this
is possible, but it opens up alot of possibilities if it is.

One could then run a cronjob (or whatever) for dpkg-secure and it
would report any of the packages that are both installed and have a
security-tagged bug assosiated with it.
The result, of course, would end up in whomever crond emails it's output to.
No insecure packages installed would generate no output and thus no email.

Maybe there could be two states?  "Insecure, unpatched" and "insecure, patched"?
That way an output parser would know what to apt-get and what to
scream to root about.
The output might involve an address to the relevant bug report or even
parts of the report itself.

Ofcourse, any bugs that are kept "secret" because they're easy for
skiddies to reproduce (or whatever) would not show up here either.
Welcome to Earth.  It's imperfect.

Anyone, feel free to pick apart my idea, and please inform me if such
a system exists and I've completely missed it.

-- 
Fredrik "Demonen" Vold
/*
- Do not meddle in the affairs of dragons, for you are crunchy and
good with ketchup.
*/

Re: Timeliness of Debian Security Announceness? (DSA 756-1 Squirrelmail)

[Bernhard R. Link]

* Herwig Wittmann <[EMAIL PROTECTED]> [050714 17:58]:
> I am trying to understand if my organization can rely on the debian
> security announcement mailing list as only source of security alerts in
> the future.

I think even when there are no temporary problems with the security
infrastructure, this is not enough. Debian's security announcement
list (and I think most other vendors' lists) only announce new
patched or updated packages.
More important is to know if you are vulnerable. Not every service
is vital, many things can be worked around temporarily, or made
impossible due to local circumstances. And as long it is not
a vulnerability found in a audit and only told the security teams,
the time between theese two events (knowledge about the problem
and availability of updated packages) is non-zero even with a perfect
security team.

Hochachtungsvoll,
Bernhard R. Link


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

Microsoft Office XP Professional with SP2 - $49.95

[Giovanny]

Adobe PhotoShop CS 8.0 - $44.95
Norton Internet Security Professional 2005 - $19.95
Norton Internet Security Professional 2005 - $19.95
QuickBooks Pro Edition 2004 - $49.95

and much more. at http://replacesoft.com/?a=3331 with fr e e e  bonus.




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

Re: Re: New squid packages 2.4.6-2woody9 restarts very often.

[Luigi Gangitano]

Hi all,
I'm investigating this issue with upstream.

> squid: rfc1035.c:410: rfc1035RRUnpack: Assertion `(*off) <= sz' failed.
> Aborted

This is the error. Incorrect parsing of DNS replies.

> Since RFC 1035 deals with DNS and the Squid patch ist meant to
> specifically fix a DNS issue, I suspect there's a bug in the patch. Not
> knowing what better to do, I'm sending this message to the security team
> per CC.

Thanks, I tried to reproduce the bug with reported url

> http://62.26.121.2/dat/bgf/trpix.gif

but didn't succeed. Can somebody please provide some more informations
like

- configuration file
- type of DNS used (BIND, dnscache, etc)
- a core file (if found)

I'm preparing a debug-enabled version to help extract more details, I'll
send to whom may be interested in helping with debug.

Regards,

-- 
 Luigi Gangitano -- <[EMAIL PROTECTED]> -- <[EMAIL PROTECTED]>
 GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972  C24A F19B A618 924C 0C26


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

Re: Timeliness of Debian Security Announceness? (DSA 756-1 Squirrelmail)

[Steve Kemp]

On Thu, Jul 14, 2005 at 05:40:22PM +0200, Herwig Wittmann wrote:

> This would be very convenient- but the delay that seems to have passed
> between the original squirrelmail security announcement and the time I
> received the alert via [EMAIL PROTECTED] is worrying:
> 
> The Vulnerability seems to have been described a few weeks ago:
> http://www.squirrelmail.org/security/issue/2005-06-15
> 
> The Debian Security Advisory 756-1 is dated July 13th, 2005.

  This has been discussed already in the archives, you should probably
 refer to those rather than reviving the subject.

  eg the following three threads:

http://lists.debian.org/debian-security/2005/06/msg00055.html

http://lists.debian.org/debian-security/2005/06/msg00097.html

http://lists.debian.org/debian-security/2005/06/msg00142.html

> I do not want to rude in any way- please try to excuse my way of putting
> things, but does anybody have a prediction how probable it is for such a
> thing to happen again?

  It's unknown whether the build infrastructure problems will recur,
 machines do die so it's possible.  The communication problems leading
 to various misunderstandings I hope will be less likely to reoccur.

> Is there a role/function in debian that is responsible for reviewing
> bugtraq or similiar sources, and is ensured that this role is fulfilled
> every day?

  The security team do follow bugtraq, etc.  Filing bugs with patches
 is a useful thing to do - but forwarding a message that has been posted
 publically already is perhaps less useful.  It's not like there's not
 enough spam mail sent to [EMAIL PROTECTED] already ;)

> Or will there be other measures in place to see that security issues are
> noticed quickly for all packages- even for strange tools that
> are not used by normal unix-centered developers?

  I'm unsure exactly what you are suggesting about less popular tools.
 Sure if five issues need fixing simultaneously the "less used" is
 liable to suffer if there's a more important bug.

  Still even less popular tools are supported, all packages should
 receive updates eventually.

Steve
--
# The Debian Security Audit Project.
http://www.debian.org/security/audit


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

Re: Timeliness of Debian Security Announceness? (DSA 756-1 Squirrelmail)

[paddy]

On Thu, Jul 14, 2005 at 05:40:22PM +0200, Herwig Wittmann wrote:
> Hi!
> 
> I am trying to understand if my organization can rely on the debian
> security announcement mailing list as only source of security alerts in
> the future.
> 
> This would be very convenient- but the delay that seems to have passed
> between the original squirrelmail security announcement and the time I
> received the alert via [EMAIL PROTECTED] is worrying:
> 
> The Vulnerability seems to have been described a few weeks ago:
> http://www.squirrelmail.org/security/issue/2005-06-15
> 
> The Debian Security Advisory 756-1 is dated July 13th, 2005.
> 
> 
> I do not want to rude in any way- please try to excuse my way of putting
> things, but does anybody have a prediction how probable it is for such a
> thing to happen again?
> 
> Is there a role/function in debian that is responsible for reviewing
> bugtraq or similiar sources, and is ensured that this role is fulfilled
> every day?
> 
> Or will there be other measures in place to see that security issues are
> noticed quickly for all packages- even for strange tools that
> are not used by normal unix-centered developers?
> 
> Kind regards,
> Herwig Wittmann

Herwig,

I hope this link will help

http://newraff.debian.org/~joeyh/stable-security.html

Regards,
Paddy
-- 
Perl 6 will give you the big knob. -- Larry Wall


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

Re: WG: critical bug in cacti

[Florian Weimer]

* Gunther Stammwitz:

> No answer yet... Does anyone know what's going on at the security
> team?

You should report publicly documented security issues to the Bug
Tracking System (with a "security" tag), and not directly to the
security team.  The BTS is read by more people, and the actual package
maintainer can comment.  From the BTS, you can see that there's
already ongoing work on a security update:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=315703
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316590


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

Re: Timeliness of Debian Security Announceness? (DSA 756-1 Squirrelmail)

[Florian Weimer]

* Herwig Wittmann:

> I do not want to rude in any way- please try to excuse my way of
> putting things, but does anybody have a prediction how probable it
> is for such a thing to happen again?

Delays in the order of weeks are pretty standard, and not always they
are caused by embargoes.  It's a bit unfortunate that the "48 hours"
claim is still on the web page.

> Is there a role/function in debian that is responsible for reviewing
> bugtraq or similiar sources, and is ensured that this role is fulfilled
> every day?

Not very formalized, but we have several persons doing public
monitoring. They file bug reports in Debian's Bug Tracking System when
they encounter public reports of security bugs.

For the most exposed packages you use, you should subscribe to the
package-specific email feed which is provided by the Package Tracking
System:

  http://packages.qa.debian.org/s/squirrelmail.html

Usually, security bugs reported publicly are filed on the same day in
the Debian BTS, especially if the package has quite a few users.

The DSA will be released when a security update for the stable
distribute is available.  As you've noticed, there can be quite some
delay.


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

Timeliness of Debian Security Announceness? (DSA 756-1 Squirrelmail)

[Herwig Wittmann]

Hi!

I am trying to understand if my organization can rely on the debian
security announcement mailing list as only source of security alerts in
the future.

This would be very convenient- but the delay that seems to have passed
between the original squirrelmail security announcement and the time I
received the alert via [EMAIL PROTECTED] is worrying:

The Vulnerability seems to have been described a few weeks ago:
http://www.squirrelmail.org/security/issue/2005-06-15

The Debian Security Advisory 756-1 is dated July 13th, 2005.


I do not want to rude in any way- please try to excuse my way of putting
things, but does anybody have a prediction how probable it is for such a
thing to happen again?

Is there a role/function in debian that is responsible for reviewing
bugtraq or similiar sources, and is ensured that this role is fulfilled
every day?

Or will there be other measures in place to see that security issues are
noticed quickly for all packages- even for strange tools that
are not used by normal unix-centered developers?

Kind regards,
Herwig Wittmann


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

Re: Hey My girl Bought me the patch

[sarah.franklin]

Title: Re: Hey My girl Bought me the patch








Sarah Franklin

Vendor Files Office Manager

ITN/NTA

18T073
Tel. 02/202.77.11

Mobile: 0476/20.62.28

email: mailto:[EMAIL PROTECTED]




 DISCLAIMER 
http://www.belgacom.be/maildisclaimer

WG: critical bug in cacti

[Gunther Stammwitz]

No answer yet... Does anyone know what's going on at the security team?

Gunther
 

-Ursprüngliche Nachricht-
Von: Gunther Stammwitz [mailto:[EMAIL PROTECTED] 
Gesendet: Sonntag, 10. Juli 2005 01:45
An: '[EMAIL PROTECTED]'
Betreff: critical bug in cacti
Wichtigkeit: Hoch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,
there seems to be a bug in cacti in the stable/SARGE-distribution that is
security critical.
one of my servers has already been exploited.
 
See www.cacti.net:

friday, july 1st, 2005 - 07:46 pm
Cacti version 0.8.6f   has been
released to address multiple security vulnerabilities discovered by the
Hardened-PHP   Project. It is recommended that
all users upgrade immediately as the 'admin' account could be compromised
under certain situations.

See the downloads page for the files and the release notes
  for further information
regarding the disclosures and patches.



Please provide new packages and a security announcement.
Placinc a .htaccess-file in front of cacti should help.

Best regards,
Gunther
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32) - WinPT 0.9.12

iD8DBQFC0GFoF7nMBgB7z7wRAn3mAJ9HP0A669kvdxouekYnyMdCS6R+2ACfexiE
ilCOGCWorN5SO6Wt7yg3jQA=
=S6um
-END PGP SIGNATURE-

Re: Document the bug fix policy regarding PHP Safe Mode

[Florian Weimer]

* Andreas Gredler:

> On Wed, Jul 13, 2005 at 08:31:25PM +0200, Florian Weimer wrote:
>  
>> Alternatives
>> 
>> Most large ISPs who run customer PHP scripts on shared hosting
>> servers do not use mod_php (or other forms of direct
>> integration into a web server), but use the CGI version of PHP, > href="http://httpd.apache.org/docs/suexec.html";>suEXEC, and a
>> different user account for each customer and proper permissions.  This
>> way, the operating system enforces the usual restrictions.
>
> Is there a security related difference between running suexec and
> running mod_php with suphp?

I don't think so, but I'm not familiar with suphp.  In the meantime,
I've been told that people like the performance improvement compared
to suexec and the CGI approach, but that's all I know about it.


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

Re: Document the bug fix policy regarding PHP Safe Mode

[Andreas Gredler]

On Wed, Jul 13, 2005 at 08:31:25PM +0200, Florian Weimer wrote:
 
> Alternatives
> 
> Most large ISPs who run customer PHP scripts on shared hosting
> servers do not use mod_php (or other forms of direct
> integration into a web server), but use the CGI version of PHP,  href="http://httpd.apache.org/docs/suexec.html";>suEXEC, and a
> different user account for each customer and proper permissions.  This
> way, the operating system enforces the usual restrictions.

Is there a security related difference between running suexec and
running mod_php with suphp?

greets Jimmy

-- 
 Andreas "Jimmy" Gredler 
   ,'"`. http://www.g-tec.co.at/ | [EMAIL PROTECTED]
  (  grml.org -» Linux for texttool-users and sysadmins
   `._,  http://www.grml.org/| [EMAIL PROTECTED]


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

Re: [SECURITY] [DSA 746-1] New packages fix remote command execution in phpgroupware

[Brian Wiese]

You may have received this comment already -- but please include the 
package name as one of the first words in the subject line as tradition, 
instead of the last -- or else I won't see it in my MUA.


i.e "New phpgroupware package fixes..." instead of above.

Thanks!
Brian

Michael Stone wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- 
Debian Security Advisory DSA 746-1   [EMAIL PROTECTED]
http://www.debian.org/security/Michael Stone
July 13, 2005 http://www.debian.org/security/faq
- 

Package: phpgroupware
Vulnerability  : remote command execution
Problem type   : input validation error
Debian-specific: no
CVE Id(s)  : CAN-2005-1921
 


--
bwiese[at]cotse.com | brianwiese.net | 402.297.9392
"What we do in life echoes in eternity" - Gladiator


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

Re: Included/staticly linked libraries in source packages:

[Florian Weimer]

* Kurt Roeckx:

> Hi Florian,
>
> Thanks for doing all of this, since it was rather manual work for me.
>
> Afaik, there are 3 kind of problems with zlib:
> - It's build-depending zlib, but linking staticly
> - It has it's own copy of zlib, and links staticly to it
> - It has it's own copy of the zlib package (ia32-libs, amd64-libs)
>
> And I have no idea which of those problems your automated tests found,
> or how you did it exactly.

There's some explanation on the web page I mentioned before:

  http://www.enyo.de/fw/security/zlib-fingerprint/

> How I would do it is check all binaries and libs to:
> - Contains zlib, like staticly linked.  I guess clamscan did that
> somehow?  Does it find all version, compiled with different compiler
> version and options?  I have no good way of finding this.

It uses generic signatures which do not depend on the architecture.
By sheer chance, right now, there isn't even a difference between the
little-endian and big-endian patterns.

> - Doesn't not have a dedepency on the zlib (objdump -p file | grep
> NEEDED)

The pattern only triggers if one of the zlib object files is linked
in, so it's not necessary to perform this additional check.

> An alternative approach I had in mind was checking all sources to
> contain the zlib source internaly.

This gives a lot of false positives (GCC, GnuPG, tons of others).

> As part of Q&A we want to get rid of those and some other libraries
> and want to make sure those are dynamicly linked to the version in
> debian.  It would be nice if we could have a list of all packages
> like this.

There's a lintian wishlist bug (#318104) which, when implemented, is a
step in this direction.

> You will of course have to take packages using tar in tar into
> account.

You mean nested archives?  Usually, this is done on purpose, but we
should keep a file somewhere which lists all such packages.

> Are you willing to those tests for some of those other packages people
> tend to include which really shouldn't be included?

I don't have a mirror on my own, so I can't test this myself.  I like
the general idea, though.

(Note that the list of packages I posted only covers zlib 1.2, copies
of zlib 1.1 were not included because they aren't affected by the
vulnerability.)


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

Included/staticly linked libraries in source packages: [Was: zlib status (CAN-2005-2096)]

[Kurt Roeckx]

Hi Florian,

Thanks for doing all of this, since it was rather manual work for me.

Afaik, there are 3 kind of problems with zlib:
- It's build-depending zlib, but linking staticly
- It has it's own copy of zlib, and links staticly to it
- It has it's own copy of the zlib package (ia32-libs, amd64-libs)

And I have no idea which of those problems your automated tests found,
or how you did it exactly.

How I would do it is check all binaries and libs to:
- Contains zlib, like staticly linked.  I guess clamscan did that
somehow?  Does it find all version, compiled with different compiler
version and options?  I have no good way of finding this.
- Doesn't not have a dedepency on the zlib (objdump -p file | grep
NEEDED)

My main problem has been the detection of the first, and I basicly was
only able to find those that are completely linked staticly, and I was
doing this by checking the build logs.

An alternative approach I had in mind was checking all sources to
contain the zlib source internaly.  As part of Q&A we want to get rid of
those and some other libraries and want to make sure those are dynamicly
linked to the version in debian.  It would be nice if we could have a
list of all packages like this.  You will of course have to take
packages using tar in tar into account.

Are you willing to those tests for some of those other packages people
tend to include which really shouldn't be included?  I had things like
gettext, boost, icu, readline, db* in mind.  Anybody else know of any
libraries we should check?


Kurt



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