Re: Apache 1.3.33 (from sarge) and mod_chroot
On Wednesday 23 March 2005 10:31 pm, Krzysztof Jóźwiak wrote: > Hello! > > My web server was hacked a few days ago and I decided to install some > new program and modules which improve security. > I find in sarge libapache-mod-chroot which chroot apache (and it work > fine) but I can't send mail from php. > I installed ssmtp in chroot (I think so) in chroot environment but it > doesn't help :( > > Does anyone use this module? Perhaps I do something wrong with it ssmtp... > It has been my experience that PHP doesn't work with ssmtp, at least not with the default ssmtp/PHP configurations in Debian. It's probably better to install exim with a minimal config anyways, so you don't lose messages if the smarthost/target system is unavailable.
Apache 1.3.33 (from sarge) and mod_chroot
Hello! My web server was hacked a few days ago and I decided to install some new program and modules which improve security. I find in sarge libapache-mod-chroot which chroot apache (and it work fine) but I can't send mail from php. I installed ssmtp in chroot (I think so) in chroot environment but it doesn't help :( Does anyone use this module? Perhaps I do something wrong with it ssmtp... -- Krzysztof Jozwiak Debian administrator -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xpdf vulnerability?
On 2005-03-23 04:07:47 -0500 Frank Küster <[EMAIL PROTECTED]> wrote: > Hubert Chan <[EMAIL PROTECTED]> wrote: > >> Is it an int or a size_t (like what malloc uses)? If it is an int, >> then INT_MAX would work as expected. If it's size_t, then you should >> use SIZE_MAX (defined in stdint.h). > > from sarge's tetex: > > , xpdf/goo/gmem.h of xpdf 2.01 | /* > | extern void *gmalloc(int size); > | extern void *grealloc(void *p, int size); > ` OK, then assuming that gmalloc is sane when it calls malloc (I think a size_t will always be at least as big as an int anyways, so it shouldn't cause a problem), then checking against INT_MAX should be safe. -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred.
Re: [DSA 694-1] New xloadimage packages fix several vulnerabilities
Bob Proulx wrote: > But the latest security upload changed the dependencies. Obviously > that was unintentional. But it is still a bad thing. > > From: > Depends: libc6 (>= 2.2.4-4), libjpeg62, libpng2(>=1.0.12), libtiff3g, xlibs > (>> 4.1.0), zlib1g (>= 1:1.1.3) > To: > Depends: libc6 (>= 2.2.4-4), libjpeg62, libpng3, libtiff3g, xlibs (>> > 4.1.0), zlib1g (>= 1:1.1.4) > > This means that an 'apt-get upgrade' will not satisfy the dependencies > of libpng3 and a dist-upgrade is required. The problem is that the original package was a binary upload compiled against libpng2 from woody. But the build depend on libpng-dev pulls in the libpng3 version. So a pbuild of the binary will automatically create a new binary bound to libpng3 instead of libpng2. This may be fixed by installing libpng2 and libpng2-dev prior to building the new package. I have verified this in a woody chroot. > > Can a new upload be made that fixes this problem? Please? Bob P.S. Still a little peeved that kdelibs3 with similar problems never got fixed. signature.asc Description: Digital signature
Re: [DSA 694-1] New xloadimage packages fix several vulnerabilities
In the security FAQ: http://www.debian.org/security/faq The most important guideline when making a new package that fixes a security problem is to make as few changes as possible. Our users and developers are relying on the exact behaviour of a release once it is made, so any change we make can possibly break someone's system. This is especially true in case of libraries: make sure you never change the Application Program Interface (API) or Application Binary Interface (ABI), no matter how small the change is. Bob Proulx wrote: > > Package: xloadimage > > Vulnerability : missing input sanitising, integer overflow > > CVE ID : CAN-2005-0638 CAN-2005-0639 > > Debian Bug : 298926 > > But the latest security upload changed the dependencies. Obviously > that was unintentional. But it is still a bad thing. > > From: > > Depends: libc6 (>= 2.2.4-4), libjpeg62, libpng2(>=1.0.12), libtiff3g, xlibs > (>> 4.1.0), zlib1g (>= 1:1.1.3) > > To: > > Depends: libc6 (>= 2.2.4-4), libjpeg62, libpng3, libtiff3g, xlibs (>> > 4.1.0), zlib1g (>= 1:1.1.4) > > This means that an 'apt-get upgrade' will not satisfy the dependencies > of libpng3 and a dist-upgrade is required. > > Can a new upload be made that fixes this problem? > > Thanks > Bob signature.asc Description: Digital signature
Re: xpdf vulnerability?
Hubert Chan <[EMAIL PROTECTED]> wrote: > On 2005-03-22 08:20:32 -0500 Frank Küster <[EMAIL PROTECTED]> wrote: > >> However, that doesn't invalidate the check. >> The main point of CAN-2004-0206, as I understand it, is that the >> upstream/original check will be performed in the limits of the widest >> integer type involved, sizeof(XRefEntry) which is 64bit on 64bit >> platforms, whereas gmalloc (which is fed the size parameter) has a >> prototype of "int". > > Is it an int or a size_t (like what malloc uses)? If it is an int, > then INT_MAX would work as expected. If it's size_t, then you should > use SIZE_MAX (defined in stdint.h). from sarge's tetex: , xpdf/goo/gmem.h of xpdf 2.01 | /* | * Same as malloc, but prints error message and exits if malloc() | * returns NULL. | */ | extern void *gmalloc(int size); | | /* | * Same as realloc, but prints error message and exits if realloc() | * returns NULL. If is NULL, calls malloc instead of realloc(). | */ | extern void *grealloc(void *p, int size); ` same in xpdf-3.00 in experimental's tetex. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: xpdf vulnerability?
Hi Javier, I'm following up on this because I want to learn, and because I'd like to write something about it for developers reference. Please don't take me as "playing dumb", at most I'm playing devils advocate, but mostly I simply didn't see the things when looking at the available information. Maybe I am dumb, but then probably other Debian maintainers are, too... Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> wrote: > On Tue, Mar 22, 2005 at 02:01:37PM +0100, Frank Küster wrote: >> >> Thank you, I found it extremely difficult (as someone who follows their >> own upstream, but not security-related mailinglists) to find ressources >> of information. Currently, the CVE IDs are often used to indicate which >> issue is talked about (like in the original mail from the >> secure-testing-team), but e.g. for CAN-2005-0206 there are no >> cross-references except the RedHat and Mandrake advisories, which aren't >> too helpful, either. > > Why not? RedHat should probably have references to their Bugzilla database > in their advisories... Oh, yes, they have some at the very bottom. However the page about CAN-2005-0206 only mentions bugs that fix the older CAN's. No, you have to look at the oldest bug, in there is the newest information. However, my point is still that this is not the information I like. In this particular case it is sufficient, probably. But in other cases the patches need not be in the BTS. Anyway, this is always information about what vendors did, not what I as a Debian maintainer should do. Aren't there any closed lists that actually discuss vulnerabilities and possible fixes before the embargo ends? And couldn't these lists be opened afterwards? > For example, if you search by CVE the Xpdf vulnerability related to > CAN-2005-0206 you will get to BID-11501: > http://www.securityfocus.com/bid/11501 > > In the 'solution' section you can see references to other vendors, and can > go searching for information on their bug tracking systems or security > advisories. Since you have a link to the version fixing it, you might do > best if you go and check their sources too. SRPM packages, for example, are > provided including both the original sources and the patches to those and > you cand download those directly from RPM vendors (RedHat, SuSE, Mandrake, > etc..) There is no occurence of "srpm" on http://www.securityfocus.com/bid/11501/solution/. And the last time I klicked on some srpm link (I think by RedHat), it required me to pay for some support contract before I would be allowed to download the sources. I'm sure there are simple ftp servers, but one first has to find them. I just checked ftp.suse.com. There are patches and src.rpm e.g. fixing CAN-2005-0064 in the i386 directory, but nothing in the ia64 directory. In the x86-64 directory, there's an xpdf file at http://ftp.suse.com/pub/suse/x86_64/update/9.0/rpm/src/xpdf-2.02pl1-148.src.rpm, but it is dated 21-Jan-2005 02:18 and can hardly fix 2004-0206. Anyway, this is *very* tedious for a maintainer who simply wants to check whether their package *is* affected at all. > Gentoo sources include the patches to the sources in their CVS and > usually reference the Bugzilla entries in their advisories (and the > bugzilla entry usually includes the patch too). Yes, the Gentoo bugzilla is quite informative. Sigh, yet an other possibility to fix this: They changed libgoo so that g*alloc accept t_int instead of int... Can't the upstream author once get things straight? > GLSA-200410-20, which is referenced to bug 69662 in Gentoo's BTS ( > http://bugs.gentoo.org/show_bug.cgi?id=69662) includes both CVE references > and provides two patches Things get even more strange: According to this, the problem that the original patches were not 64bit-safe were already known on 2004-10-31. And it does not make things clearer with respect to 0888 vs. 0889; the two patches are just one against libgoo, the other against XRef (and not patching Catalog.cc...). It seems to me every distribution, and every upstream using xpdf code have used a different fix. We should really ask Foolabs to provide a libxpdf (Debian bug #252104), or else switch to libpoppler as much as possible. > In any case, from the Gentoo's BTS, it looks like this was disclosed first > on Vendor-Sec (a private mailing list used by open source distributions) so > you might want to send off a mail to the Security Team asking them to > forward you the relevant mails. I thought they were Cc'ed with my first mails, but I always mix up "debian-security@lists.debian.org" with "[EMAIL PROTECTED]". Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
