Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 01:09:46PM +0100, Jørgen Hermanrud Fjeld wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Tuesday 13 November 2001 09:52, Ethan Benson wrote: > > 2.4 is also especially problematic on i386 since you have to fit it on > > all these archaic 1.22MB floppies and such. > > Hmm, I thought the 2.4 kernel was quite compact, and sometimes smaller, when > compiled than the 2.2, ( I don't know though. ) quite the opposite, its much much larger. > Having had the need of a 2.2.13 kernel for installing Debian on a machine > with HW RAID and reiserfs, I rolled my own boot disks. Although I didnt > install lots of stuff in my kernel, it isn't overly sized. > This is 'df -h' when mounting the rescue disk for 1220 floppy: > > /usr/src/boot-floppies/resc1200.bin > 1.2M 993k 192k 84% /usr/src/boot-floppies/resc > > This kernel is admittedly not very versatile. > I'll attach my config file as well > My drivers.tgz file is quite small, but then again, I have very few modules. > > I assume someone have tried making 1220 floppies with 2.4.x, finding it > difficult, and were not just assuming? yes, see -boot archives. > And will the next generation bootstrap system make it any easier to switch? > If not, what is crucial for the switch to happen? debian-installer is not anywhere near ready for prime-time and won't be used for woody, development is concentrated on boot-floppies otherwise we will never have any kind of working install system. besides the size problem the decision is not up to -boot, i386 woody will ship with 2.2.19 or 2.2.20, that is not going to change. (aph the boot-floppies maintainer has spoken on this already). -- Ethan Benson http://www.alaska.net/~erbenson/ pgp9UJ6NynyV6.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 01:09:46PM +0100, Jørgen Hermanrud Fjeld wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Tuesday 13 November 2001 09:52, Ethan Benson wrote: > > 2.4 is also especially problematic on i386 since you have to fit it on > > all these archaic 1.22MB floppies and such. > > Hmm, I thought the 2.4 kernel was quite compact, and sometimes smaller, when > compiled than the 2.2, ( I don't know though. ) quite the opposite, its much much larger. > Having had the need of a 2.2.13 kernel for installing Debian on a machine > with HW RAID and reiserfs, I rolled my own boot disks. Although I didnt > install lots of stuff in my kernel, it isn't overly sized. > This is 'df -h' when mounting the rescue disk for 1220 floppy: > > /usr/src/boot-floppies/resc1200.bin > 1.2M 993k 192k 84% /usr/src/boot-floppies/resc > > This kernel is admittedly not very versatile. > I'll attach my config file as well > My drivers.tgz file is quite small, but then again, I have very few modules. > > I assume someone have tried making 1220 floppies with 2.4.x, finding it > difficult, and were not just assuming? yes, see -boot archives. > And will the next generation bootstrap system make it any easier to switch? > If not, what is crucial for the switch to happen? debian-installer is not anywhere near ready for prime-time and won't be used for woody, development is concentrated on boot-floppies otherwise we will never have any kind of working install system. besides the size problem the decision is not up to -boot, i386 woody will ship with 2.2.19 or 2.2.20, that is not going to change. (aph the boot-floppies maintainer has spoken on this already). -- Ethan Benson http://www.alaska.net/~erbenson/ msg04172/pgp0.pgp Description: PGP signature
Re: Vulnerable SSH versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 13 November 2001 09:52, Ethan Benson wrote: > 2.4 is also especially problematic on i386 since you have to fit it on > all these archaic 1.22MB floppies and such. Hmm, I thought the 2.4 kernel was quite compact, and sometimes smaller, when compiled than the 2.2, ( I don't know though. ) Having had the need of a 2.2.13 kernel for installing Debian on a machine with HW RAID and reiserfs, I rolled my own boot disks. Although I didnt install lots of stuff in my kernel, it isn't overly sized. This is 'df -h' when mounting the rescue disk for 1220 floppy: /usr/src/boot-floppies/resc1200.bin 1.2M 993k 192k 84% /usr/src/boot-floppies/resc This kernel is admittedly not very versatile. I'll attach my config file as well My drivers.tgz file is quite small, but then again, I have very few modules. I assume someone have tried making 1220 floppies with 2.4.x, finding it difficult, and were not just assuming? And will the next generation bootstrap system make it any easier to switch? If not, what is crucial for the switch to happen? Sincerely Jørgen Hermanrud Fjeld [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjvxDYoACgkQCx+ABR2dqkKcJgCeLAsxAxETIuFvSlGCIvtCqA1G HugAniu8q0CN9GIoeWyJdNhpYgvxn6Iu =IwVG -END PGP SIGNATURE- # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_M386=y # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_X86_CMPXCHG is not set # CONFIG_X86_XADD is not set CONFIG_X86_L1_CACHE_SHIFT=4 CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_SMP is not set # CONFIG_X86_UP_APIC is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # CONFIG_PNPBIOS is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set CONFIG_BLK_DEV_DAC960=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_MD_MULTIPATH is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set CONFIG_INET_ECN=y CONFIG_INET_ECN_DISABLED=y CONFIG_SYN_COOKIES=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=
Re: Vulnerable SSH versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 13 November 2001 09:52, Ethan Benson wrote: > 2.4 is also especially problematic on i386 since you have to fit it on > all these archaic 1.22MB floppies and such. Hmm, I thought the 2.4 kernel was quite compact, and sometimes smaller, when compiled than the 2.2, ( I don't know though. ) Having had the need of a 2.2.13 kernel for installing Debian on a machine with HW RAID and reiserfs, I rolled my own boot disks. Although I didnt install lots of stuff in my kernel, it isn't overly sized. This is 'df -h' when mounting the rescue disk for 1220 floppy: /usr/src/boot-floppies/resc1200.bin 1.2M 993k 192k 84% /usr/src/boot-floppies/resc This kernel is admittedly not very versatile. I'll attach my config file as well My drivers.tgz file is quite small, but then again, I have very few modules. I assume someone have tried making 1220 floppies with 2.4.x, finding it difficult, and were not just assuming? And will the next generation bootstrap system make it any easier to switch? If not, what is crucial for the switch to happen? Sincerely Jørgen Hermanrud Fjeld [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjvxDYoACgkQCx+ABR2dqkKcJgCeLAsxAxETIuFvSlGCIvtCqA1G HugAniu8q0CN9GIoeWyJdNhpYgvxn6Iu =IwVG -END PGP SIGNATURE- # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_M386=y # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_X86_CMPXCHG is not set # CONFIG_X86_XADD is not set CONFIG_X86_L1_CACHE_SHIFT=4 CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_SMP is not set # CONFIG_X86_UP_APIC is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # CONFIG_PNPBIOS is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set CONFIG_BLK_DEV_DAC960=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_MD_MULTIPATH is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set CONFIG_INET_ECN=y CONFIG_INET_ECN_DISABLED=y CONFIG_SYN_COOKIES=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABL
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 09:02:46AM +0100, Stefan Schwandter wrote: > On Mon, Nov 12, 2001 at 04:54:04PM -0900, Ethan Benson wrote: > > > > Which makes me wonder, why ship Woody with 2.2.20 at all? Oh well, not > > > my decision. > > > because 2.4 is not stable yet. > > Hmmm... I think it will take some months before woody is released. Don't > you think 2.4 will have stabilized enough by that time? because then we have to break boot-floppies and start the long arduous process of stabelizing them all over again. 2.4 is also especially problematic on i386 since you have to fit it on all these archaic 1.22MB floppies and such. however do note that some of debian's architectures will ship with 2.4 simply because 2.2 doesn't properly support them, or 2.4 is actually more stable then 2.2 (due to the various stages porting work is/was at). for the curious here is the current rundown: ifeq "$(architecture)" "alpha" kver:= 2.2.19 endif ifeq "$(architecture)" "arm" kver:= 2.2.19 endif ifeq "$(architecture)" "i386" kver:= 2.2.19 endif ifeq "$(architecture)" "m68k" kver:= 2.2.19 endif ifeq "$(architecture)" "powerpc" kver:= 2.2.19 pcmcia_kver := 2.2.19-pmac apuskver:= 2.2.10 endif ifeq "$(architecture)" "sparc" kver:= 2.2.19 kver_sun4u := 2.4.10 endif ifeq "$(architecture)" "ia64" kver:= 2.4.9 endif ifeq "$(architecture)" "hppa" kver:= 2.4.9 endif ifeq "$(architecture)" "mips" kver:= 2.4.9 endif ifeq "$(architecture)" "mipsel" kver:= 2.4.9 endif ifeq "$(architecture)" "s390" kver:= 2.4.7 endif so if you want a 2.4 kernel by default switch to one of the above 2.4 listed architectures :P otherwise just apt-get install kernel-image-2.4.YY after install. -- Ethan Benson http://www.alaska.net/~erbenson/ pgptkDFeXMNI2.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Mon, Nov 12, 2001 at 04:54:04PM -0900, Ethan Benson wrote: > > Which makes me wonder, why ship Woody with 2.2.20 at all? Oh well, not > > my decision. > because 2.4 is not stable yet. Hmmm... I think it will take some months before woody is released. Don't you think 2.4 will have stabilized enough by that time? regards, Stefan
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 09:02:46AM +0100, Stefan Schwandter wrote: > On Mon, Nov 12, 2001 at 04:54:04PM -0900, Ethan Benson wrote: > > > > Which makes me wonder, why ship Woody with 2.2.20 at all? Oh well, not > > > my decision. > > > because 2.4 is not stable yet. > > Hmmm... I think it will take some months before woody is released. Don't > you think 2.4 will have stabilized enough by that time? because then we have to break boot-floppies and start the long arduous process of stabelizing them all over again. 2.4 is also especially problematic on i386 since you have to fit it on all these archaic 1.22MB floppies and such. however do note that some of debian's architectures will ship with 2.4 simply because 2.2 doesn't properly support them, or 2.4 is actually more stable then 2.2 (due to the various stages porting work is/was at). for the curious here is the current rundown: ifeq "$(architecture)" "alpha" kver:= 2.2.19 endif ifeq "$(architecture)" "arm" kver:= 2.2.19 endif ifeq "$(architecture)" "i386" kver:= 2.2.19 endif ifeq "$(architecture)" "m68k" kver:= 2.2.19 endif ifeq "$(architecture)" "powerpc" kver:= 2.2.19 pcmcia_kver := 2.2.19-pmac apuskver:= 2.2.10 endif ifeq "$(architecture)" "sparc" kver:= 2.2.19 kver_sun4u := 2.4.10 endif ifeq "$(architecture)" "ia64" kver:= 2.4.9 endif ifeq "$(architecture)" "hppa" kver:= 2.4.9 endif ifeq "$(architecture)" "mips" kver:= 2.4.9 endif ifeq "$(architecture)" "mipsel" kver:= 2.4.9 endif ifeq "$(architecture)" "s390" kver:= 2.4.7 endif so if you want a 2.4 kernel by default switch to one of the above 2.4 listed architectures :P otherwise just apt-get install kernel-image-2.4.YY after install. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04170/pgp0.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Mon, Nov 12, 2001 at 04:54:04PM -0900, Ethan Benson wrote: > > Which makes me wonder, why ship Woody with 2.2.20 at all? Oh well, not > > my decision. > because 2.4 is not stable yet. Hmmm... I think it will take some months before woody is released. Don't you think 2.4 will have stabilized enough by that time? regards, Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vulnerable SSH versions
On 2001-11-12 16:54 Ethan Benson wrote: On Tue, Nov 13, 2001 at 10:10:10AM +0900, Howland, Curtis wrote: CH> Which makes me wonder, why ship Woody with 2.2.20 at all? Oh well, not CH> my decision. EB> because 2.4 is not stable yet. *applause* I was hoping for that. Great decision. In fact the only acceptable thing to do when we think of the current 2.4.x mess. Regards, Øyvind +== http://www.sunbase.org/sunny ===+ | OpenPGP: 0xAD19826C 2000-01-24 Øyvind A. Holm <[EMAIL PROTECTED]> | | Fingerprint: EAE5 DCA0 0626 5DAA 72F8 0435 2E2B E476 AD19 826C | +=== 2 + 2 = 5 for extremely large values of 2. +
Re: Vulnerable SSH versions
On 2001-11-12 16:54 Ethan Benson wrote: On Tue, Nov 13, 2001 at 10:10:10AM +0900, Howland, Curtis wrote: CH> Which makes me wonder, why ship Woody with 2.2.20 at all? Oh well, not CH> my decision. EB> because 2.4 is not stable yet. *applause* I was hoping for that. Great decision. In fact the only acceptable thing to do when we think of the current 2.4.x mess. Regards, Ãyvind +== http://www.sunbase.org/sunny ===+ | OpenPGP: 0xAD19826C 2000-01-24 Ãyvind A. Holm <[EMAIL PROTECTED]> | | Fingerprint: EAE5 DCA0 0626 5DAA 72F8 0435 2E2B E476 AD19 826C | +=== 2 + 2 = 5 for extremely large values of 2. + -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vulnerable SSH versions
On Mon, Nov 12, 2001 at 05:54:04PM -0800, Ethan Benson wrote: > On Tue, Nov 13, 2001 at 10:10:10AM +0900, Howland, Curtis wrote: > > I will gladly grant that the tar file may not exist for the boot > > floppies, and that I do not have on hand the CD to check it. It also > may > > have been a Potato(e) phenominon, no longer in use. However, it did > > exist. > yes releases before woody uses a base tarball. thats not done > anymore, base tarballs are obsolete. > > Which makes me wonder, why ship Woody with 2.2.20 at all? Oh well, not > > my decision. > because 2.4 is not stable yet. You can say that again. -- Share and Enjoy.
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 10:10:10AM +0900, Howland, Curtis wrote: > I will gladly grant that the tar file may not exist for the boot > floppies, and that I do not have on hand the CD to check it. It also may > have been a Potato(e) phenominon, no longer in use. However, it did > exist. yes releases before woody uses a base tarball. thats not done anymore, base tarballs are obsolete. > Which makes me wonder, why ship Woody with 2.2.20 at all? Oh well, not > my decision. because 2.4 is not stable yet. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpiHMwRxTruy.pgp Description: PGP signature
RE: Vulnerable SSH versions
I will gladly grant that the tar file may not exist for the boot floppies, and that I do not have on hand the CD to check it. It also may have been a Potato(e) phenominon, no longer in use. However, it did exist. Which makes me wonder, why ship Woody with 2.2.20 at all? Oh well, not my decision. I'm not sure that the problem is the 2.2.x modules "being found" by the 2.4.x modutils, I had the distinct impression that they were just "still included" for some reason. However, again to my shame, I have not the machine accessable to check. However, this is way off topic no matter how interesting. Thanks to everyone for their help and advice, we shall see. Curt- -Original Message- From: Henrique de Moraes Holschuh [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 13, 2001 09:53 To: Howland, Curtis Cc: debian-security@lists.debian.org Subject: Re: Vulnerable SSH versions On Tue, 13 Nov 2001, Howland, Curtis wrote: > The tar file that contains the "base" Woody install, which is used as > the jumping off point for installation. There isn't one, at least not for bootflopies. We use debootstrap to fetch the most up-to-date packages of that distribution and install them, not a tarball. > As far as the change from 2.2.x to 2.4.x, if you don't think it was all > that confusing then you don't use pcmcia services. The 2.2.x kernel That looks like a quite bad usability bug on the pcmcia-related packages to me, but I have not looked deeply (read: not at all) into the problem. > modules are all still there, but they no longer work. That means that > not only do you need to find out the new modules names, you have to > ensure you don't use any of the old ones. The 2.2.x modules should not be kept somewhere the 2.4 kernels will find them. This is certainly a big problem. > Seriously flawed, IMNSHO, and very confusing. It also led to a version > conflict with modutils, where I had to boot back into 2.2.x in order to > install modutils v2.4.10. I still get error messages from modutils on > both boot-up and shutdown about version conflicts and missing modules. Please file bugs against the appropriate packages, so as to have them insure they have a new-enough modutils, at the very least. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 09:41:54AM +0900, Howland, Curtis wrote: > The tar file that contains the "base" Woody install, which is used as > the jumping off point for installation. there is no such thing. > The tar file has binary kernel, /boot, /proc and other directories, I'm > not sure exactly what the limit to its contents is. I found this out by > building a CD via the "assemble the CD image from individual .deb > packages" procedure. there is no tarball containing any of this. boot-floppies install the kernel they were built with and then run debootstrap to install the base system from the debian archive (.debs). baseX_Y.tgz is dead and has been for a long time. > As far as the change from 2.2.x to 2.4.x, if you don't think it was all > that confusing then you don't use pcmcia services. The 2.2.x kernel > modules are all still there, but they no longer work. That means that > not only do you need to find out the new modules names, you have to > ensure you don't use any of the old ones. correct i don't use pcmcia, but as i understand it pcmcia modules are obsolete in 2.4, which should save a fsckload of problems. > Seriously flawed, IMNSHO, and very confusing. It also led to a version > conflict with modutils, where I had to boot back into 2.2.x in order to > install modutils v2.4.10. I still get error messages from modutils on > both boot-up and shutdown about version conflicts and missing modules. woody will, and is of course installed with 2.4 capable modutils as for transitions of pcmcia related stuff you have to take that up with the maintainers of the relevant packages. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpHSCnb7IBvH.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Tue, 13 Nov 2001, Howland, Curtis wrote: > The tar file that contains the "base" Woody install, which is used as > the jumping off point for installation. There isn't one, at least not for bootflopies. We use debootstrap to fetch the most up-to-date packages of that distribution and install them, not a tarball. > As far as the change from 2.2.x to 2.4.x, if you don't think it was all > that confusing then you don't use pcmcia services. The 2.2.x kernel That looks like a quite bad usability bug on the pcmcia-related packages to me, but I have not looked deeply (read: not at all) into the problem. > modules are all still there, but they no longer work. That means that > not only do you need to find out the new modules names, you have to > ensure you don't use any of the old ones. The 2.2.x modules should not be kept somewhere the 2.4 kernels will find them. This is certainly a big problem. > Seriously flawed, IMNSHO, and very confusing. It also led to a version > conflict with modutils, where I had to boot back into 2.2.x in order to > install modutils v2.4.10. I still get error messages from modutils on > both boot-up and shutdown about version conflicts and missing modules. Please file bugs against the appropriate packages, so as to have them insure they have a new-enough modutils, at the very least. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
RE: Vulnerable SSH versions
The tar file that contains the "base" Woody install, which is used as the jumping off point for installation. The tar file has binary kernel, /boot, /proc and other directories, I'm not sure exactly what the limit to its contents is. I found this out by building a CD via the "assemble the CD image from individual .deb packages" procedure. As far as the change from 2.2.x to 2.4.x, if you don't think it was all that confusing then you don't use pcmcia services. The 2.2.x kernel modules are all still there, but they no longer work. That means that not only do you need to find out the new modules names, you have to ensure you don't use any of the old ones. Seriously flawed, IMNSHO, and very confusing. It also led to a version conflict with modutils, where I had to boot back into 2.2.x in order to install modutils v2.4.10. I still get error messages from modutils on both boot-up and shutdown about version conflicts and missing modules. Curt- -Original Message- From: Ethan Benson [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 13, 2001 09:33 To: debian-security@lists.debian.org Subject: Re: Vulnerable SSH versions On Tue, Nov 13, 2001 at 09:25:29AM +0900, Howland, Curtis wrote: > Thanks. > > I've been keeping it up to date weekly or so, but just to be sure I > changed the sources.list to be "... potato/..." instead of "... > stable/..." for when "stable" changes. > > Even a blank-disk install of Woody wasn't straight forward. The kernel > in the distribution tar file was 2.2.xx, changing to 2.4.9 was a bitch, > and it's already up to 2.4.12 or .14... I wonder if the tar file has > been changed to reflect the new kernel realities? what tarfile? woody will ship with 2.2.20, but it will fully support 2.4 kernels, i don't know whats so difficult about installing one. -- Ethan Benson http://www.alaska.net/~erbenson/
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 09:25:29AM +0900, Howland, Curtis wrote: > Thanks. > > I've been keeping it up to date weekly or so, but just to be sure I > changed the sources.list to be "... potato/..." instead of "... > stable/..." for when "stable" changes. > > Even a blank-disk install of Woody wasn't straight forward. The kernel > in the distribution tar file was 2.2.xx, changing to 2.4.9 was a bitch, > and it's already up to 2.4.12 or .14... I wonder if the tar file has > been changed to reflect the new kernel realities? what tarfile? woody will ship with 2.2.20, but it will fully support 2.4 kernels, i don't know whats so difficult about installing one. -- Ethan Benson http://www.alaska.net/~erbenson/ pgp4sMLzlcrfJ.pgp Description: PGP signature
RE: Vulnerable SSH versions
Thanks. I've been keeping it up to date weekly or so, but just to be sure I changed the sources.list to be "... potato/..." instead of "... stable/..." for when "stable" changes. Even a blank-disk install of Woody wasn't straight forward. The kernel in the distribution tar file was 2.2.xx, changing to 2.4.9 was a bitch, and it's already up to 2.4.12 or .14... I wonder if the tar file has been changed to reflect the new kernel realities? Curt- -Original Message- From: Ethan Benson [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 13, 2001 09:15 To: debian-security@lists.debian.org Subject: Re: Vulnerable SSH versions On Tue, Nov 13, 2001 at 09:02:56AM +0900, Howland, Curtis wrote: > A quick question concerning such things... > > I have a remote server that I do not trust myself to upgrade from > Potato(e) to Woody, and such vulnerabilities do worry me a little. Is > there any general expectation that such "back porting" will continue > once Woody is released? when potato was released security updates for slink were discontinued two monthes later. since potato is going to be even more fosselized then slink was by the time woody is released i would expect a similar timeframe (that and potato only has 6(?) architectures woody will have something like 12 or more). expect to have two months to upgrade your potato boxes before being on your own in regards to security updates. -- Ethan Benson http://www.alaska.net/~erbenson/
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 09:02:56AM +0900, Howland, Curtis wrote: > A quick question concerning such things... > > I have a remote server that I do not trust myself to upgrade from > Potato(e) to Woody, and such vulnerabilities do worry me a little. Is > there any general expectation that such "back porting" will continue > once Woody is released? when potato was released security updates for slink were discontinued two monthes later. since potato is going to be even more fosselized then slink was by the time woody is released i would expect a similar timeframe (that and potato only has 6(?) architectures woody will have something like 12 or more). expect to have two months to upgrade your potato boxes before being on your own in regards to security updates. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpbXfbo3CZy6.pgp Description: PGP signature
Re: Vulnerable SSH versions
Previously Howland, Curtis wrote: > I have a remote server that I do not trust myself to upgrade from > Potato(e) to Woody, and such vulnerabilities do worry me a little. Is > there any general expectation that such "back porting" will continue > once Woody is released? I expect only for a limited period of time (few months). Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
RE: Vulnerable SSH versions
A quick question concerning such things... I have a remote server that I do not trust myself to upgrade from Potato(e) to Woody, and such vulnerabilities do worry me a little. Is there any general expectation that such "back porting" will continue once Woody is released? Curt- -Original Message- From: Jo Fahlke [mailto:[EMAIL PROTECTED] Sent: Monday, November 12, 2001 19:45 To: Michal Kara Cc: debian-security@lists.debian.org Subject: Re: Vulnerable SSH versions Am Mon, 12. Nov 2001, 11:30:49 +0100 schrieb Michal Kara: > Hi there! > > During this weekend, there has been paper posted to bugtraq named "Analysis of > SSH crc32 compensation attack detector exploit". It talks about a recorded > successful exploit using overflow in CRC32 compensation attack detection code, a > hole, which was discovered in February this year. > > In the appendices, there is also program checking if you are vulnerable by > checking the version string SSH daemon produces on connect. The newest Dewbian > Potato version produces string "SSH-1.5-OpenSSH-1.2.3" which is listed as > vulnerable to this security hole. However, the Debian advisory released in > February says refers to version 1.2.3 as having this fixed... > > So how it is? Who is wrong? > > Thanks, > Michal Check out the thread starting at http://lists.debian.org/debian-security/2001/debian-security-200111/msg0 0025.html Basicly, in Debian potato the fix was backported to the old Version of ssh so it should be safe. Jö. -- If God had intended Man to Smoke, He would have set him on Fire. -- fortune
Re: Vulnerable SSH versions
On Mon, Nov 12, 2001 at 05:54:04PM -0800, Ethan Benson wrote: > On Tue, Nov 13, 2001 at 10:10:10AM +0900, Howland, Curtis wrote: > > I will gladly grant that the tar file may not exist for the boot > > floppies, and that I do not have on hand the CD to check it. It also > may > > have been a Potato(e) phenominon, no longer in use. However, it did > > exist. > yes releases before woody uses a base tarball. thats not done > anymore, base tarballs are obsolete. > > Which makes me wonder, why ship Woody with 2.2.20 at all? Oh well, not > > my decision. > because 2.4 is not stable yet. You can say that again. -- Share and Enjoy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 10:10:10AM +0900, Howland, Curtis wrote: > I will gladly grant that the tar file may not exist for the boot > floppies, and that I do not have on hand the CD to check it. It also may > have been a Potato(e) phenominon, no longer in use. However, it did > exist. yes releases before woody uses a base tarball. thats not done anymore, base tarballs are obsolete. > Which makes me wonder, why ship Woody with 2.2.20 at all? Oh well, not > my decision. because 2.4 is not stable yet. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04162/pgp0.pgp Description: PGP signature
RE: Vulnerable SSH versions
I will gladly grant that the tar file may not exist for the boot floppies, and that I do not have on hand the CD to check it. It also may have been a Potato(e) phenominon, no longer in use. However, it did exist. Which makes me wonder, why ship Woody with 2.2.20 at all? Oh well, not my decision. I'm not sure that the problem is the 2.2.x modules "being found" by the 2.4.x modutils, I had the distinct impression that they were just "still included" for some reason. However, again to my shame, I have not the machine accessable to check. However, this is way off topic no matter how interesting. Thanks to everyone for their help and advice, we shall see. Curt- -Original Message- From: Henrique de Moraes Holschuh [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 09:53 To: Howland, Curtis Cc: [EMAIL PROTECTED] Subject: Re: Vulnerable SSH versions On Tue, 13 Nov 2001, Howland, Curtis wrote: > The tar file that contains the "base" Woody install, which is used as > the jumping off point for installation. There isn't one, at least not for bootflopies. We use debootstrap to fetch the most up-to-date packages of that distribution and install them, not a tarball. > As far as the change from 2.2.x to 2.4.x, if you don't think it was all > that confusing then you don't use pcmcia services. The 2.2.x kernel That looks like a quite bad usability bug on the pcmcia-related packages to me, but I have not looked deeply (read: not at all) into the problem. > modules are all still there, but they no longer work. That means that > not only do you need to find out the new modules names, you have to > ensure you don't use any of the old ones. The 2.2.x modules should not be kept somewhere the 2.4 kernels will find them. This is certainly a big problem. > Seriously flawed, IMNSHO, and very confusing. It also led to a version > conflict with modutils, where I had to boot back into 2.2.x in order to > install modutils v2.4.10. I still get error messages from modutils on > both boot-up and shutdown about version conflicts and missing modules. Please file bugs against the appropriate packages, so as to have them insure they have a new-enough modutils, at the very least. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 09:41:54AM +0900, Howland, Curtis wrote: > The tar file that contains the "base" Woody install, which is used as > the jumping off point for installation. there is no such thing. > The tar file has binary kernel, /boot, /proc and other directories, I'm > not sure exactly what the limit to its contents is. I found this out by > building a CD via the "assemble the CD image from individual .deb > packages" procedure. there is no tarball containing any of this. boot-floppies install the kernel they were built with and then run debootstrap to install the base system from the debian archive (.debs). baseX_Y.tgz is dead and has been for a long time. > As far as the change from 2.2.x to 2.4.x, if you don't think it was all > that confusing then you don't use pcmcia services. The 2.2.x kernel > modules are all still there, but they no longer work. That means that > not only do you need to find out the new modules names, you have to > ensure you don't use any of the old ones. correct i don't use pcmcia, but as i understand it pcmcia modules are obsolete in 2.4, which should save a fsckload of problems. > Seriously flawed, IMNSHO, and very confusing. It also led to a version > conflict with modutils, where I had to boot back into 2.2.x in order to > install modutils v2.4.10. I still get error messages from modutils on > both boot-up and shutdown about version conflicts and missing modules. woody will, and is of course installed with 2.4 capable modutils as for transitions of pcmcia related stuff you have to take that up with the maintainers of the relevant packages. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04160/pgp0.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Tue, 13 Nov 2001, Howland, Curtis wrote: > The tar file that contains the "base" Woody install, which is used as > the jumping off point for installation. There isn't one, at least not for bootflopies. We use debootstrap to fetch the most up-to-date packages of that distribution and install them, not a tarball. > As far as the change from 2.2.x to 2.4.x, if you don't think it was all > that confusing then you don't use pcmcia services. The 2.2.x kernel That looks like a quite bad usability bug on the pcmcia-related packages to me, but I have not looked deeply (read: not at all) into the problem. > modules are all still there, but they no longer work. That means that > not only do you need to find out the new modules names, you have to > ensure you don't use any of the old ones. The 2.2.x modules should not be kept somewhere the 2.4 kernels will find them. This is certainly a big problem. > Seriously flawed, IMNSHO, and very confusing. It also led to a version > conflict with modutils, where I had to boot back into 2.2.x in order to > install modutils v2.4.10. I still get error messages from modutils on > both boot-up and shutdown about version conflicts and missing modules. Please file bugs against the appropriate packages, so as to have them insure they have a new-enough modutils, at the very least. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Vulnerable SSH versions
The tar file that contains the "base" Woody install, which is used as the jumping off point for installation. The tar file has binary kernel, /boot, /proc and other directories, I'm not sure exactly what the limit to its contents is. I found this out by building a CD via the "assemble the CD image from individual .deb packages" procedure. As far as the change from 2.2.x to 2.4.x, if you don't think it was all that confusing then you don't use pcmcia services. The 2.2.x kernel modules are all still there, but they no longer work. That means that not only do you need to find out the new modules names, you have to ensure you don't use any of the old ones. Seriously flawed, IMNSHO, and very confusing. It also led to a version conflict with modutils, where I had to boot back into 2.2.x in order to install modutils v2.4.10. I still get error messages from modutils on both boot-up and shutdown about version conflicts and missing modules. Curt- -Original Message- From: Ethan Benson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 09:33 To: [EMAIL PROTECTED] Subject: Re: Vulnerable SSH versions On Tue, Nov 13, 2001 at 09:25:29AM +0900, Howland, Curtis wrote: > Thanks. > > I've been keeping it up to date weekly or so, but just to be sure I > changed the sources.list to be "... potato/..." instead of "... > stable/..." for when "stable" changes. > > Even a blank-disk install of Woody wasn't straight forward. The kernel > in the distribution tar file was 2.2.xx, changing to 2.4.9 was a bitch, > and it's already up to 2.4.12 or .14... I wonder if the tar file has > been changed to reflect the new kernel realities? what tarfile? woody will ship with 2.2.20, but it will fully support 2.4 kernels, i don't know whats so difficult about installing one. -- Ethan Benson http://www.alaska.net/~erbenson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 09:25:29AM +0900, Howland, Curtis wrote: > Thanks. > > I've been keeping it up to date weekly or so, but just to be sure I > changed the sources.list to be "... potato/..." instead of "... > stable/..." for when "stable" changes. > > Even a blank-disk install of Woody wasn't straight forward. The kernel > in the distribution tar file was 2.2.xx, changing to 2.4.9 was a bitch, > and it's already up to 2.4.12 or .14... I wonder if the tar file has > been changed to reflect the new kernel realities? what tarfile? woody will ship with 2.2.20, but it will fully support 2.4 kernels, i don't know whats so difficult about installing one. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04157/pgp0.pgp Description: PGP signature
RE: Vulnerable SSH versions
Thanks. I've been keeping it up to date weekly or so, but just to be sure I changed the sources.list to be "... potato/..." instead of "... stable/..." for when "stable" changes. Even a blank-disk install of Woody wasn't straight forward. The kernel in the distribution tar file was 2.2.xx, changing to 2.4.9 was a bitch, and it's already up to 2.4.12 or .14... I wonder if the tar file has been changed to reflect the new kernel realities? Curt- -Original Message- From: Ethan Benson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 13, 2001 09:15 To: [EMAIL PROTECTED] Subject: Re: Vulnerable SSH versions On Tue, Nov 13, 2001 at 09:02:56AM +0900, Howland, Curtis wrote: > A quick question concerning such things... > > I have a remote server that I do not trust myself to upgrade from > Potato(e) to Woody, and such vulnerabilities do worry me a little. Is > there any general expectation that such "back porting" will continue > once Woody is released? when potato was released security updates for slink were discontinued two monthes later. since potato is going to be even more fosselized then slink was by the time woody is released i would expect a similar timeframe (that and potato only has 6(?) architectures woody will have something like 12 or more). expect to have two months to upgrade your potato boxes before being on your own in regards to security updates. -- Ethan Benson http://www.alaska.net/~erbenson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vulnerable SSH versions
On Tue, Nov 13, 2001 at 09:02:56AM +0900, Howland, Curtis wrote: > A quick question concerning such things... > > I have a remote server that I do not trust myself to upgrade from > Potato(e) to Woody, and such vulnerabilities do worry me a little. Is > there any general expectation that such "back porting" will continue > once Woody is released? when potato was released security updates for slink were discontinued two monthes later. since potato is going to be even more fosselized then slink was by the time woody is released i would expect a similar timeframe (that and potato only has 6(?) architectures woody will have something like 12 or more). expect to have two months to upgrade your potato boxes before being on your own in regards to security updates. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04155/pgp0.pgp Description: PGP signature
Re: Vulnerable SSH versions
Previously Howland, Curtis wrote: > I have a remote server that I do not trust myself to upgrade from > Potato(e) to Woody, and such vulnerabilities do worry me a little. Is > there any general expectation that such "back porting" will continue > once Woody is released? I expect only for a limited period of time (few months). Wichert. -- _ [EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Vulnerable SSH versions
A quick question concerning such things... I have a remote server that I do not trust myself to upgrade from Potato(e) to Woody, and such vulnerabilities do worry me a little. Is there any general expectation that such "back porting" will continue once Woody is released? Curt- -Original Message- From: Jo Fahlke [mailto:[EMAIL PROTECTED]] Sent: Monday, November 12, 2001 19:45 To: Michal Kara Cc: [EMAIL PROTECTED] Subject: Re: Vulnerable SSH versions Am Mon, 12. Nov 2001, 11:30:49 +0100 schrieb Michal Kara: > Hi there! > > During this weekend, there has been paper posted to bugtraq named "Analysis of > SSH crc32 compensation attack detector exploit". It talks about a recorded > successful exploit using overflow in CRC32 compensation attack detection code, a > hole, which was discovered in February this year. > > In the appendices, there is also program checking if you are vulnerable by > checking the version string SSH daemon produces on connect. The newest Dewbian > Potato version produces string "SSH-1.5-OpenSSH-1.2.3" which is listed as > vulnerable to this security hole. However, the Debian advisory released in > February says refers to version 1.2.3 as having this fixed... > > So how it is? Who is wrong? > > Thanks, > Michal Check out the thread starting at http://lists.debian.org/debian-security/2001/debian-security-200111/msg0 0025.html Basicly, in Debian potato the fix was backported to the old Version of ssh so it should be safe. Jö. -- If God had intended Man to Smoke, He would have set him on Fire. -- fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vulnerable SSH versions
* Michal Kara <[EMAIL PROTECTED]> [02 11:35]: > Hi there! Hi > During this weekend, there has been paper posted to bugtraq named > "Analysis of SSH crc32 compensation attack detector exploit". It > talks about a recorded successful exploit using overflow in CRC32 > compensation attack detection code, a hole, which was discovered in > February this year. > > In the appendices, there is also program checking if you are > vulnerable by checking the version string SSH daemon produces on > connect. The newest Dewbian Potato version produces string > "SSH-1.5-OpenSSH-1.2.3" which is listed as vulnerable to this > security hole. However, the Debian advisory released in February > says refers to version 1.2.3 as having this fixed... > > So how it is? Who is wrong? I *think* both are right. The paper you mention talks about the original openssh 1.2.3 whereas the debian advisory talks about the debian package. It's not the same. This is the same issue as discussed last week. The message I got was that the ssh package in potato includes a patch which fixes the vulnerability. The patch doesn't change the version number, of course. Such a patch was given in http://razor.bindview.com/publish/advisories/adv_ssh1crc.html If you don't believe the debian advisory, you have to check the source code, I think. Best, Ville
Re: Vulnerable SSH versions
Am Mon, 12. Nov 2001, 11:30:49 +0100 schrieb Michal Kara: > Hi there! > > During this weekend, there has been paper posted to bugtraq named "Analysis > of > SSH crc32 compensation attack detector exploit". It talks about a recorded > successful exploit using overflow in CRC32 compensation attack detection > code, a > hole, which was discovered in February this year. > > In the appendices, there is also program checking if you are vulnerable by > checking the version string SSH daemon produces on connect. The newest Dewbian > Potato version produces string "SSH-1.5-OpenSSH-1.2.3" which is listed as > vulnerable to this security hole. However, the Debian advisory released in > February says refers to version 1.2.3 as having this fixed... > > So how it is? Who is wrong? > > Thanks, > Michal Check out the thread starting at http://lists.debian.org/debian-security/2001/debian-security-200111/msg00025.html Basicly, in Debian potato the fix was backported to the old Version of ssh so it should be safe. Jö. -- If God had intended Man to Smoke, He would have set him on Fire. -- fortune pgp7ebPjRhZOg.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Mon, Nov 12, 2001 at 11:30:49AM +0100, Michal Kara wrote: > Hi there! > > During this weekend, there has been paper posted to bugtraq named "Analysis > of > SSH crc32 compensation attack detector exploit". It talks about a recorded > successful exploit using overflow in CRC32 compensation attack detection > code, a > hole, which was discovered in February this year. > > In the appendices, there is also program checking if you are vulnerable by > checking the version string SSH daemon produces on connect. The newest Dewbian > Potato version produces string "SSH-1.5-OpenSSH-1.2.3" which is listed as > vulnerable to this security hole. However, the Debian advisory released in > February says refers to version 1.2.3 as having this fixed... > > So how it is? Who is wrong? debian backports security fixes to whatever version is in stable, they don't just slop new upstream versions into stable to take care of security bugs. -- Ethan Benson http://www.alaska.net/~erbenson/ pgpFKqK4VNhsJ.pgp Description: PGP signature
Re: Vulnerable SSH versions
* Michal Kara <[EMAIL PROTECTED]> [02 11:35]: > Hi there! Hi > During this weekend, there has been paper posted to bugtraq named > "Analysis of SSH crc32 compensation attack detector exploit". It > talks about a recorded successful exploit using overflow in CRC32 > compensation attack detection code, a hole, which was discovered in > February this year. > > In the appendices, there is also program checking if you are > vulnerable by checking the version string SSH daemon produces on > connect. The newest Dewbian Potato version produces string > "SSH-1.5-OpenSSH-1.2.3" which is listed as vulnerable to this > security hole. However, the Debian advisory released in February > says refers to version 1.2.3 as having this fixed... > > So how it is? Who is wrong? I *think* both are right. The paper you mention talks about the original openssh 1.2.3 whereas the debian advisory talks about the debian package. It's not the same. This is the same issue as discussed last week. The message I got was that the ssh package in potato includes a patch which fixes the vulnerability. The patch doesn't change the version number, of course. Such a patch was given in http://razor.bindview.com/publish/advisories/adv_ssh1crc.html If you don't believe the debian advisory, you have to check the source code, I think. Best, Ville -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vulnerable SSH versions
Am Mon, 12. Nov 2001, 11:30:49 +0100 schrieb Michal Kara: > Hi there! > > During this weekend, there has been paper posted to bugtraq named "Analysis of > SSH crc32 compensation attack detector exploit". It talks about a recorded > successful exploit using overflow in CRC32 compensation attack detection code, a > hole, which was discovered in February this year. > > In the appendices, there is also program checking if you are vulnerable by > checking the version string SSH daemon produces on connect. The newest Dewbian > Potato version produces string "SSH-1.5-OpenSSH-1.2.3" which is listed as > vulnerable to this security hole. However, the Debian advisory released in > February says refers to version 1.2.3 as having this fixed... > > So how it is? Who is wrong? > > Thanks, > Michal Check out the thread starting at http://lists.debian.org/debian-security/2001/debian-security-200111/msg00025.html Basicly, in Debian potato the fix was backported to the old Version of ssh so it should be safe. Jö. -- If God had intended Man to Smoke, He would have set him on Fire. -- fortune msg04144/pgp0.pgp Description: PGP signature
Re: Vulnerable SSH versions
On Mon, Nov 12, 2001 at 11:30:49AM +0100, Michal Kara wrote: > Hi there! > > During this weekend, there has been paper posted to bugtraq named "Analysis of > SSH crc32 compensation attack detector exploit". It talks about a recorded > successful exploit using overflow in CRC32 compensation attack detection code, a > hole, which was discovered in February this year. > > In the appendices, there is also program checking if you are vulnerable by > checking the version string SSH daemon produces on connect. The newest Dewbian > Potato version produces string "SSH-1.5-OpenSSH-1.2.3" which is listed as > vulnerable to this security hole. However, the Debian advisory released in > February says refers to version 1.2.3 as having this fixed... > > So how it is? Who is wrong? debian backports security fixes to whatever version is in stable, they don't just slop new upstream versions into stable to take care of security bugs. -- Ethan Benson http://www.alaska.net/~erbenson/ msg04143/pgp0.pgp Description: PGP signature
