Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)
On 14/01/2014 22:25, Steven Chamberlain wrote:
Thankfully wheezy's 9.0 and 8.3 kernels had not enabled
either of those RNGs yet.
Are you sure? This is from 9.0:
void
random_ident_hardware(struct random_systat *systat)
{
/* Set default to software */
*systat = random_yarrow;
/* Then go looking for hardware */
#if defined(__i386__) !defined(PC98)
if (via_feature_rng VIA_HAS_RNG) {
*systat = random_nehemiah;
}
#endif
}
--
Robert Millan
--
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/52d5bc4b.90...@debian.org
Fwd: Re: Fwd: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)
Forwarding to the other lists from original thread... Original Message Subject: Re: Fwd: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources) Date: Sun, 15 Dec 2013 20:53:19 +0100 From: Yves-Alexis Perez cor...@debian.org To: Robert Millan r...@debian.org CC: t...@security.debian.org On Sat, Dec 14, 2013 at 12:27:27PM +0100, Robert Millan wrote: Used the wrong address for Security Team. Sorry! Original Message Subject: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources) Date: Sat, 14 Dec 2013 01:44:16 +0100 From: Robert Millan r...@debian.org To: debian-security@lists.debian.org CC: debian-ker...@lists.debian.org, debian-...@lists.debian.org debian-...@lists.debian.org According this publication [0], The New York Times, Pro Publica, and The Guardian, reported in September that the NSA and its British counterpart are working with chipmakers to insert backdoors, or cryptographic weaknesses, in their products. [0] http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/ Software trusting chip-based crypto support, and in particular software which uses specialized chips to obtain entropy might be compromising the quality of the entropy pool as made available to /dev/random. This has been recently discussed at security conference in EuroBSDcon 2013. The minutes read: we are going to backtrack and remove RDRAND and Padlock backends and feed them into Yarrow instead of delivering their output directly to /dev/random. It will still be possible to access hardware random number generators, that is, RDRAND, Padlock etc., directly by inline assembly or by using OpenSSL from userland, if required, but we cannot trust them any more (from http://www.freebsd.org/news/status/report-2013-09-devsummit.html#Security) In consequence the FreeBSD project has deemed it necessary to unlink entropy providers in Intel RDRAND and Via Padlock technologies from the main /dev/random source (http://svnweb.freebsd.org/base?view=revisionrevision=256377). Advice from Security Team would be appreciated in order to determine which action needs to be taken in Debian. Well, considering kFreeBSD is not more than a technology preview at that point and the fact it's never been considered really safe to really on one single source of entropy (be it hardware based or not, rumored backdoored or not), I'm not sure we need to rush for a kFreeBSD DSA. That beeing said, I'm all for pushing updates backporting the fixed behavior of mixing everything, but I guess that can be part of a more general release. Regards, -- Yves-Alexis -- 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/52ae247c.9040...@debian.org
Re: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)
On 14/12/2013 02:08, Henrique de Moraes Holschuh wrote: kfreebsd 8.3 and 9.0 (wheezy): Sets Via chipset to serve /dev/random unconditionally whenever detected, but only on i386 (not amd64). Does not support Intel entropy source. (see sys/dev/random/probe.c) Backporting the fix to these kernels might be a good idea, probably best routed through an stable update upload (and not a security upload). This might be a bit complicated due to significant changes in internal APIs. I'm also unsure if the yarrow algorithms used in those versions are good enough for the task. Perhaps we should just disable Via chipset from sys/dev/random/probe.c. Would this be a terrible loss for a Technology Preview release? kfreebsd 9.2 (jessie / sid): Sets Via or Intel chipset to serve /dev/random when detected, unless hw.nehemiah_rng_enable or hw.ivy_rng_enable are set to zero to disable them. Remove, switch to kfreebsd 10. Either that, or backport the fix from kfreebsd 10. I tend to favour removal. Releasing with two kernels is a PITA. What does everyone else think? Is someone interested in having 9.2 in jessie? -- Robert Millan -- 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/52ae28d1.3040...@debian.org
possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)
According this publication [0], The New York Times, Pro Publica, and The Guardian, reported in September that the NSA and its British counterpart are working with chipmakers to insert backdoors, or cryptographic weaknesses, in their products. [0] http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/ Software trusting chip-based crypto support, and in particular software which uses specialized chips to obtain entropy might be compromising the quality of the entropy pool as made available to /dev/random. This has been recently discussed at security conference in EuroBSDcon 2013. The minutes read: we are going to backtrack and remove RDRAND and Padlock backends and feed them into Yarrow instead of delivering their output directly to /dev/random. It will still be possible to access hardware random number generators, that is, RDRAND, Padlock etc., directly by inline assembly or by using OpenSSL from userland, if required, but we cannot trust them any more (from http://www.freebsd.org/news/status/report-2013-09-devsummit.html#Security) In consequence the FreeBSD project has deemed it necessary to unlink entropy providers in Intel RDRAND and Via Padlock technologies from the main /dev/random source (http://svnweb.freebsd.org/base?view=revisionrevision=256377). Advice from Security Team would be appreciated in order to determine which action needs to be taken in Debian. --- Here's my best attempt at determining the behaviour of kFreeBSD relative to Intel RDRAND / Via Padlock entropy sources: kfreebsd 8.3 and 9.0 (wheezy): Sets Via chipset to serve /dev/random unconditionally whenever detected, but only on i386 (not amd64). Does not support Intel entropy source. (see sys/dev/random/probe.c) kfreebsd 9.2 (jessie / sid): Sets Via or Intel chipset to serve /dev/random when detected, unless hw.nehemiah_rng_enable or hw.ivy_rng_enable are set to zero to disable them. kfreebsd 10~ (sid): All versions in Debian already have the fixed code, which replaces random_adaptor_register() with live_entropy_source_register(), thereby registering Via and Intel chips as entropy sources to be post processed by Yarrow, rather than directly as random adaptors. -- Robert Millan -- 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/52aba9e0.2060...@debian.org
Re: [rt.debian.org #3892] AutoReply CC: kfreebsd-8: cve-2012-0217
2012/6/21 Steven Chamberlain ste...@pyro.eu.org: I'm assuming you created that RT ticket? I was included on Cc:, but I can't view via the web without an account. Yes. I included you on CC. The web interface is at http://rt.debian.org, but I'm not sure if I'm allowed to give access to others (maybe ask DSA?). I also didn't see the initial post and don't know the status of this. Sorry. It seems I can't check the status either, even though I created the ticket myself :-( I tried to follow up just now to a comment (I can't see the author) that was posted and I've no idea if my reply was accepted. Just wanted to check this with you in case my reply to RT isn't visible: On 21/06/12 18:36, Debian Developer via RT wrote: Careful, patch in SVN repository can't be used as-is. See: http://lists.debian.org/debian-bsd/2012/06/msg00214.html My reply: After querying it with upstream they confirmed it was incorrect (ineffective), has now been fixed, and I already committed r4320 which matches upstream's correction. Please also see my follwup on debian-bsd: https://lists.debian.org/debian-bsd/2012/06/msg00246.html In other words the current SVN is fine for release. Hopefully soon, because the exploit is due to be be demonstrated publicly tomorrow. CCing debian-security. Hopefully someone will pick this up... -- Robert Millan -- 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/caofdtxntero8j4kmj3x3phk-emerzteb6bygkmg4rtvw6d1...@mail.gmail.com
Re: Bug#631161: kfreebsd-8: cve-2011-2480 info disclosure
2011/6/21 Michael Gilbert michael.s.gilb...@gmail.com:
looking at the commit itself [0], i find Dan's conclusion rather
surprising. the affected code is in the 802.11 stack, so it seems like
it should be platform-independent. i doubt x86 is any better at
handling signedness issues, but i suppose i could be missing something.
Fix uploaded to unstable and experimental.
debian-security: Patch is available in r3480 in glibc-bsd SVN (attached
for your convenience).
--
Robert Millan
Index: debian/changelog
===
--- debian/changelog(revision 3479)
+++ debian/changelog(revision 3480)
@@ -1,3 +1,11 @@
+kfreebsd-8 (8.1+dfsg-8+squeeze1) UNRELEASED; urgency=low
+
+ * Fix net802.11 stack kernel memory disclosure (CVE-2011-2480).
+(Closes: #631160)
+- 000_net80211_disclosure.diff
+
+ -- Robert Millan r...@debian.org Sat, 25 Jun 2011 13:24:06 +0200
+
kfreebsd-8 (8.1+dfsg-8) stable-proposed-updates; urgency=low
[ Petr Salinger ]
Index: debian/patches/series
===
--- debian/patches/series (revision 3479)
+++ debian/patches/series (revision 3480)
@@ -3,6 +3,7 @@
000_coda.diff
000_ufs_lookup.diff
000_tcp_usrreq.diff
+000_net80211_disclosure.diff
001_misc.diff
003_glibc_dev_aicasm.diff
004_xargs.diff
Index: debian/patches/000_net80211_disclosure.diff
===
--- debian/patches/000_net80211_disclosure.diff (revision 0)
+++ debian/patches/000_net80211_disclosure.diff (revision 3480)
@@ -0,0 +1,79 @@
+--- a/sys/net80211/ieee80211_acl.c
b/sys/net80211/ieee80211_acl.c
+@@ -77,7 +77,7 @@
+ struct aclstate {
+ acl_lock_t as_lock;
+ int as_policy;
+- int as_nacls;
++ uint32_tas_nacls;
+ TAILQ_HEAD(, acl) as_list;/* list of all ACL's */
+ LIST_HEAD(, acl)as_hash[ACL_HASHSIZE];
+ struct ieee80211vap *as_vap;
+@@ -289,7 +289,8 @@
+ struct aclstate *as = vap-iv_as;
+ struct acl *acl;
+ struct ieee80211req_maclist *ap;
+- int error, space, i;
++ int error;
++ uint32_t i, space;
+
+ switch (ireq-i_val) {
+ case IEEE80211_MACCMD_POLICY:
+--- a/sys/net80211/ieee80211_ioctl.c
b/sys/net80211/ieee80211_ioctl.c
+@@ -141,7 +141,7 @@
+ ieee80211_ioctl_getchaninfo(struct ieee80211vap *vap, struct ieee80211req
*ireq)
+ {
+ struct ieee80211com *ic = vap-iv_ic;
+- int space;
++ uint32_t space;
+
+ space = __offsetof(struct ieee80211req_chaninfo,
+ ic_chans[ic-ic_nchans]);
+@@ -205,7 +205,7 @@
+ {
+ struct ieee80211_node *ni;
+ uint8_t macaddr[IEEE80211_ADDR_LEN];
+- const int off = __offsetof(struct ieee80211req_sta_stats, is_stats);
++ const size_t off = __offsetof(struct ieee80211req_sta_stats, is_stats);
+ int error;
+
+ if (ireq-i_len off)
+@@ -321,7 +321,7 @@
+ if (req.space ireq-i_len)
+ req.space = ireq-i_len;
+ if (req.space 0) {
+- size_t space;
++ uint32_t space;
+ void *p;
+
+ space = req.space;
+@@ -456,7 +456,7 @@
+
+ static __noinline int
+ getstainfo_common(struct ieee80211vap *vap, struct ieee80211req *ireq,
+- struct ieee80211_node *ni, int off)
++ struct ieee80211_node *ni, size_t off)
+ {
+ struct ieee80211com *ic = vap-iv_ic;
+ struct stainforeq req;
+@@ -501,7 +501,7 @@
+ ieee80211_ioctl_getstainfo(struct ieee80211vap *vap, struct ieee80211req
*ireq)
+ {
+ uint8_t macaddr[IEEE80211_ADDR_LEN];
+- const int off = __offsetof(struct ieee80211req_sta_req, info);
++ const size_t off = __offsetof(struct ieee80211req_sta_req, info);
+ struct ieee80211_node *ni;
+ int error;
+
+--- a/sys/net80211/ieee80211_ioctl.h
b/sys/net80211/ieee80211_ioctl.h
+@@ -578,7 +578,7 @@
+ chari_name[IFNAMSIZ]; /* if_name, e.g. wi0 */
+ uint16_ti_type; /* req type */
+ int16_t i_val; /* Index or simple value */
+- int16_t i_len; /* Index or simple value */
++ uint16_ti_len; /* Index or simple value */
+ void*i_data;/* Extra data */
+ };
+ #define SIOCS80211 _IOW('i', 234, struct ieee80211req)
Install kfreebsd-i386 using squeeze/testing
I tested the daily build today, but instead of installing unstable, I told it to install from testing/squeeze. Seems to be working fine. The only caveat is that D-I is unable to setup the security URIs because http://security.debian.org/ doesn't generate kfreebsd-i386 indices yet. Even if security support is not available, I think it'd be a good idea to have those generated. CCing debian-security (I think it's the appropiate list for this request). -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
GCC code duplication in gcc-mingw32
Hi, The FTP team has decided that gcc-mingw32 (ITP #529183) must not be built by build-depending on gcc-4.4-source and dynamically using the tarball provided by that package, because current archive infrastructure cannot garantee that corresponding source for gcc-mingw32 binaries will always be available (which is a GPL requirement). As a least bad alternative, gcc-mingw32 will include a copy of gcc 4.4 sources in its own .orig.tar.gz. Mark Hymers asked me to notify both -release and -security, so that you're aware gcc code will be duplicated in this way. I expect this problem can be resolved in a better way in the future when DAK has better support for handling this kind of situation. -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [SECURITY] [DSA 993-1] New GnuPG packages fix broken signature check
On Fri, Mar 10, 2006 at 09:37:25PM +0100, Martin Schulze wrote: For the unstable distribution (sid) this problem has been fixed in version 1.4.2.2-1. ITYM 1.4.2-1 -- Robert Millan a href=http://linuxstolescocode.com/;SCO/a a href=http://sco.com/;losers/ap a href=http://www.whitehouse.gov/president/gwbbio.html;miserable failure/ap -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SECURITY] [DSA 609-1] New atari800 packages fix local root exploit
On Tue, Dec 14, 2004 at 05:03:01PM +0100, Martin Schulze wrote: Adam Zabrocki discovered multiple buffer overflows in atari800, an Atari emulator. In order to directly access graphics hardware, one of the affected programs is installed setuid root. A local attacker could exploit this vulnerability to gain root privileges. I wonder if we could have some sort of policy to prevent this kind of silly bugs. It doesn't make sense to use root privs for displaying graphics when we have priviledge separation layers like SDL and X. -- .''`. Proudly running Debian GNU/kFreeBSD unstable/unreleased (on UFS2+S) : :' : `. `'http://www.debian.org/ports/kfreebsd-gnu `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
vulnerabilities in CVS?
Hi! Are we affected by this? I haven't seen any DSA. On Mon, Sep 20, 2004 at 01:50:33PM +, FreeBSD Security Advisories wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = FreeBSD-SA-04:14.cvs.asc Security Advisory The FreeBSD Project Topic: CVS Category: contrib Module: cvs Announced: 2004-09-19 Credits:Stefan Esser, Sebastian Krahmer, Derek Price iDEFENSE Affects:All FreeBSD versions Corrected: 2004-06-29 16:10:50 UTC (RELENG_4) 2004-09-19 22:26:22 UTC (RELENG_4_10, 4.10-RELEASE-p3) 2004-09-19 22:27:36 UTC (RELENG_4_9, 4.9-RELEASE-p12) 2004-09-19 22:28:14 UTC (RELENG_4_8, 4.8-RELEASE-p25) 2004-09-19 22:37:10 UTC (RELENG_5_2, 5.2.1-RELEASE-p10) CVE Name: CAN-2004-0414, CAN-2004-0416, CAN-2004-0417, CAN-2004-0418, CAN-2004-0778 FreeBSD only: NO For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit URL:http://www.freebsd.org/security/. I. Background The Concurrent Versions System (CVS) is a version control system. It may be used to access a repository locally, or to access a `remote repository' using a number of different methods. When accessing a remote repository, the target machine runs the CVS server to fulfill client requests. II. Problem Description A number of vulnerabilities were discovered in CVS by Stefan Esser, Sebastian Krahmer, and Derek Price. . Insufficient input validation while processing Entry lines. (CAN-2004-0414) . A double-free resulting from erroneous state handling while processing Argumentx commands. (CAN-2004-0416) . Integer overflow while processing Max-dotdot commands. (CAN-2004-0417) . Erroneous handling of empty entries handled while processing Notify commands. (CAN-2004-0418) . A format string bug while processing CVS wrappers. . Single-byte buffer underflows while processing configuration files from CVSROOT. . Various other integer overflows. Additionally, iDEFENSE reports an undocumented command-line flag used in debugging does not perform input validation on the given path names. III. Impact CVS servers (cvs server or :pserver: modes) are affected by these vulnerabilities. They vary in impact but include information disclosure (the iDEFENSE-reported bug), denial-of-service (CAN-2004-0414, CAN-2004-0416, CAN-2004-0417 and other bugs), or possibly arbitrary code execution (CAN-2004-0418). In very special situations where the attacker may somehow influence the contents of CVS configuration files in CVSROOT, additional attacks may be possible. IV. Workaround Disable the use of remote CVS repositories. V. Solution Do one of the following: 1) Upgrade your vulnerable system to the RELENG_4 stable branch, or to the RELENG_5_2, RELENG_4_10, RELENG_4_9, or RELENG_4_8 security branch dated after the correction date. OR 2) Patch your present system: The following patches have been verified to apply to FreeBSD 4.8, 4.9, 4.10 and 5.2.1 systems. Note that one *must* have previously applied the patches pertaining to FreeBSD-SA-04:10.cvs in order to use these patches. Note that FreeBSD 4.10-STABLE systems built from sources dated 2004-06-29 16:20:00 UTC or later include cvs 1.11.17, which has all of these issues fixed. These patches should not be applied to those systems. a) Download the relevant patches from the location below, and verify the detached PGP signature using your PGP utility. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:14/cvs.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-04:14/cvs.patch.asc b) Execute the following commands as root: # cd /usr/src # patch /path/to/patch # cd /usr/src/gnu/usr.bin/cvs # make obj make depend make make install VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - - RELENG_4_10 src/UPDATING 1.73.2.90.2.4 src/sys/conf/newvers.sh 1.44.2.34.2.5 src/contrib/cvs/lib/xsize.h 1.1.1.1.6.1 src/contrib/cvs/src/commit.c1.8.2.5.6.1 src/contrib/cvs/src/cvs.h 1.11.2.6.6.1 src/contrib/cvs/src/filesubr.c 1.6.2.4.6.1 src/contrib/cvs/src/history.c
Re: Bug#264846: telnet: Buffer Overrun by unchecked environment variables
On Thu, Aug 12, 2004 at 10:04:52AM +0200, Bernhard R. Link wrote: I may be utterly confused, but that patch does look quite strange. It may make it near to impossible to introduce code, but only reduces the problem: strncpy will not '\0'-terminate the string, so that the following /.telnetrc will be written to some random position. and even if there was some termination, 127 chars plus 10 chars for /.telnetrc is still more than the reserved 128. (thus when having $HOME 116 to 126 chars one could even control where the /.telnetrc letters get to). That patch is wrong. Please direct your comments at the patch for dynamic allocation I just sent instead. -- Robert Millan (Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\ (kernel of *(Berkeley Software Distribution)) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#264846: telnet: Buffer Overrun by unchecked environment variables
On Tue, Aug 10, 2004 at 10:12:06AM -0700, Josh Martin wrote:
-- no debconf information
Although this should never actually happen, if you set your environment
variable HOME to an extremely large string a buffer overflow will occur upon
connecting to a server using telnet.
Urgh.. This really calls for an upload to t-p-u.
I was not able to overwrite 'eip'
but I have included a patch that fixes this problem.
Could you overwrite esp/ebp? Anyway, I'm CCing the security team for
assistance on the impact. I don't think it's release-critical since a
tainted HOME already implies there's a flaw somewhere.
--- commands.orig.cc 2004-08-10 09:50:44.0 -0700
+++ commands.cc 2004-08-10 09:51:07.0 -0700
@@ -2148,7 +2148,7 @@
if (rcname == 0) {
rcname = getenv(HOME);
if (rcname)
- strcpy(rcbuf, rcname);
+ strncpy(rcbuf, rcname, 127);
else
rcbuf[0] = '\0';
strcat(rcbuf, /.telnetrc);
I don't like it. This keeps the 127-byte hardcoded limit. What would you
think about:
--- netkit-telnet-0.17/telnet/commands.cc~ 2004-05-19 01:56:10.0 +0200
+++ netkit-telnet-0.17/telnet/commands.cc 2004-08-11 21:32:02.0 +0200
@@ -2139,22 +2139,14 @@
}
void cmdrc(const char *m1, const char *m2, const char *port) {
-static char *rcname = 0;
-static char rcbuf[128];
+static char *rcname;
if (skiprc) return;
readrc(m1, m2, port, /etc/telnetrc);
-if (rcname == 0) {
- rcname = getenv(HOME);
- if (rcname)
- strcpy(rcbuf, rcname);
- else
- rcbuf[0] = '\0';
- strcat(rcbuf, /.telnetrc);
- rcname = rcbuf;
-}
+asprintf (rcname, %s/.telnetrc, getenv (HOME));
readrc(m1, m2, port, rcname);
+free (rcname);
}
#if defined(IP_OPTIONS) defined(HAS_IPPROTO_IP)
Let me know if I screwed on something, we need to be extra careful with
standard packages during the freeze..
--
Robert Millan
(Debra and Ian) (Gnu's Not (UNiplexed Information and Computing System))/\
(kernel of *(Berkeley Software Distribution))
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ftp.gnu.org cracked
On 18/08/03 13:58:16, Matt Zimmerman wrote: If we're going to make a statement about it, we should have some facts to release. For example, if someone would like to verify the validity of the GNU source tarballs that we ship against the checksums published by GNU, that would be great. I think this is a task for the respective maintainers of GNU software in Debian, but if someone pops up that'd really help. My suggestion otherwise is that someone sends an alert message to - devel-announce explaining that: - maintainers of GNU software in Debian should verify the correctness of their packages in the Debian archive. - Debian members who accessed a Debian machine from gnuftp are encouraged to change their password. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ftp.gnu.org cracked
On 18/08/03 13:58:16, Matt Zimmerman wrote: If we're going to make a statement about it, we should have some facts to release. For example, if someone would like to verify the validity of the GNU source tarballs that we ship against the checksums published by GNU, that would be great. I think this is a task for the respective maintainers of GNU software in Debian, but if someone pops up that'd really help. My suggestion otherwise is that someone sends an alert message to - devel-announce explaining that: - maintainers of GNU software in Debian should verify the correctness of their packages in the Debian archive. - Debian members who accessed a Debian machine from gnuftp are encouraged to change their password. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
Fwd: ftp.gnu.org cracked
from debian-private:
On Mon, Aug 18, 2003 at 02:51:55AM +, Robert Millan wrote:
Hi there,
As you might have already heard, a root compromise, which presumably has been
there for two months, was recently detected in {ftp,alpha}.gnu.org
(read http://ftp.gnu.org/MISSING-FILES.README for details)
The following paragraph should draw attention for Debian:
The modus operandi of the cracker shows that (s)he was interested primarily
in using gnuftp to collect passwords and as a launching point to attack other
machines.
1) Some Debian developers do also have GNU accounts, in case any of them
had the (bad, bad) idea of accessing a Debian machine from ftp.gnu.org
this could compromise the Debian machine park.
2) Any unsigned sources in ftp.gnu.org could have been trojaned during
the March-July period, and most of GNU packages have their corresponding
packages in the Debian archive. It is clear there's a risk that the Debian
archive could have been compromised.
What do you suggest to do? First, can this dicussion be disclosed? (e.g:
into debian-security). Then how can we deal with these two problems? Would
an alert message to -devel-announce suffice?
--
Robert Millan
[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work.
-- J.R.R.T, Ainulindale (Silmarillion)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ftp.gnu.org cracked
[ Moving to debian-security ] On Mon, Aug 18, 2003 at 12:35:44PM +1000, Russell Coker wrote: On Mon, 18 Aug 2003 12:51, Robert Millan wrote: 2) Any unsigned sources in ftp.gnu.org could have been trojaned during the March-July period, and most of GNU packages have their corresponding packages in the Debian archive. It is clear there's a risk that the Debian archive could have been compromised. The current evidence suggests that this has not happened. However there is a risk of a trojan having been put in an application that has new versions released often which resulted in the trojaned version being over-written in the normal course of operations. Also there is the possibility that a trojaned version was put online and then the original was restored by the attacker, I think that this is unlikely as restoring the original version would probably be more likely to get them caught. Then the question is, how are we going to cope with that risk? The minimal action that comes to my mind is an alert in -devel-announce, any other ideas around? What do you suggest to do? First, can this dicussion be disclosed? (e.g: into debian-security). Then how can we deal with these two problems? Would an alert message to -devel-announce suffice? The hack of the GNU server is no secret, and neither is our reliance on GNU software. I think that anyone who knows anything about Debian can work out the issues for themselves. Therefore trying to keep this secret gains us nothing and only gives a risk of more concern. I suggest publicising everything. ok. moved this thread to debian-security. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ftp.gnu.org cracked
[ Moving to debian-security ] On Mon, Aug 18, 2003 at 12:35:44PM +1000, Russell Coker wrote: On Mon, 18 Aug 2003 12:51, Robert Millan wrote: 2) Any unsigned sources in ftp.gnu.org could have been trojaned during the March-July period, and most of GNU packages have their corresponding packages in the Debian archive. It is clear there's a risk that the Debian archive could have been compromised. The current evidence suggests that this has not happened. However there is a risk of a trojan having been put in an application that has new versions released often which resulted in the trojaned version being over-written in the normal course of operations. Also there is the possibility that a trojaned version was put online and then the original was restored by the attacker, I think that this is unlikely as restoring the original version would probably be more likely to get them caught. Then the question is, how are we going to cope with that risk? The minimal action that comes to my mind is an alert in -devel-announce, any other ideas around? What do you suggest to do? First, can this dicussion be disclosed? (e.g: into debian-security). Then how can we deal with these two problems? Would an alert message to -devel-announce suffice? The hack of the GNU server is no secret, and neither is our reliance on GNU software. I think that anyone who knows anything about Debian can work out the issues for themselves. Therefore trying to keep this secret gains us nothing and only gives a risk of more concern. I suggest publicising everything. ok. moved this thread to debian-security. -- Robert Millan [..] but the delight and pride of Aule is in the deed of making, and in the thing made, and neither in possession nor in his own mastery; wherefore he gives and hoards not, and is free from care, passing ever on to some new work. -- J.R.R.T, Ainulindale (Silmarillion)
possible hole in mozilla et al
Hi, Just noticed this advisory, stating a remote vulnerability in mozilla: http://sec.greymagic.com/adv/gm001-ns/ It claims to affect 0.9.7+ but on 1.0 all it does is crashing my browser. Please CC to contact me, not subscribed. -- Robert Millan 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5 Andrew S. Tanenbaum, 30 Jan 1992 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
