Both bugs are mentionned in http://archives.neohapsis.com/archives/fulldisclosure/2006-04/0639.html . There are both fixed in SVN http://www.openttd.org/nightly.php ----------------------------------------------- A] program termination through big error number ----------------------------------------------- Both client and server handle a type of command (PACKET_SERVER_ERROR and PACKET_CLIENT_ERROR) for the visualization of some pre-built errors in the console. The problem happens when an attacker sends an invalid big error number (8 bit) which forces the program to terminate spontaneously through the usage of the error() function. The bug is exploitable only in-game so the attacker must have access to the server: his IP must not be banned, he must know the password if it has been set and the server must not be full. >From strings.c: char *GetStringWithArgs(char *buffr, uint string, const int32 *argv) { uint index = GB(string, 0, 11); uint tab = GB(string, 11, 5); ... if (index >= _langtab_num[tab]) { error( "!String 0x%X is invalid. " "Probably because an old version of the .lng file.\n", string ); } return FormatString(buffr, GetStringPtr(GB(string, 0, 16)), argv, GB(string, 24, 8)); } ------------------------------------------------------ B] broadcast clients disconnection in multiplayer menu ------------------------------------------------------ Clients are affected by an harmless bug when they handle UDP packets. The first 2 bytes of each UDP packet are a 16 bit number which specifies the size of the packet. If this value in a received packet is invalid (for example too small) the client returns immediately to the main menu. This bug becomes problematic when a malicious server visible in the master server list sends invalid replies to the queries sent from the clients which want to play online and will be no longer able to do it due to the returning to the main menu.
Our stable ebuild (0.4.0.1-r1) is NOT affected by bug A. (it does not contain the quoted extract of code, from strings.c). Consequently, no GLSA will be issued for this vuln. I can't say if we are vulnerable to bug B : security team or game team, please advise :) Our ~arch ebuild (0.4.7) seems to be vulnerable to bug A. (it contains the quoted extract of code, from strings.c) In all cases, the current SVN is known to be patched, but i can't isolate the good patches.
Be sure to cc the maintainer for stuff like this.
David, please advise
David seems to be MIA, games team might have an opinion on what to do on this one ?
I've masked 0.4.7 and up, but would really think the best solution for us, as the "backup" for the maintainer, is to wait for the next version. Has anyone verified if we are/are not vulnerable to bug B with the current stable?
masked, setting to enhancement status. Let's have a vote about a temp maskingglsa: voting no here.
Voting "no", too.
policy says no maskglsa for a B3
I added those versions of openttd to portage. dholm gave his okay to me. So let me be responsible for further actions on this bug.
could somebody responsible please adjust the package.mask to say that only 0.4.7 is blocked. 0.4.8_rc* do contain the fixes.
Done.
openttd-0.4.8 is out and in portage.
OK we should try to test and stabilize it since there are probably some of our users who haven't unmerged the vulnerable ebuild. Arches, please could you test and stabilize one of the "-0.4.8(_rc.)?" ebuilds ?
I don't feel very comfortable with stabilizing release candidates, especially if they're unofficial. Is 0.4.8 ready for stable, or is that not an option?
> Is 0.4.8 ready for stable, i think so > or is that not an option? -0.4.8 is matched by "-0.4.8(_rc.)?" :)
(In reply to comment #14) > Is 0.4.8 ready for stable, or is that not an option? From my point of view it's ready for stable. But it's in portage for just two days now.
> > Is 0.4.8 ready for stable, or is that not an option? > > From my point of view it's ready for stable. But it's in portage for just two > days now. We stablized tons of software only one or two days or even hours after it was put in the tree if it fixed a security issue. Also, this is a game and not a core package, so it shouldn't be such a problem, should it? :)
[ebuild N ] games-simulation/openttd-0.4.8 USE="alsa png scenarios zlib -debug -dedicated -timidity" 1) emerges fine 2) passes collision test 3) I don't have the original game, so I cannot play it Portage 2.1-r2 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.17-gentoo-r4 i686) ================================================================= System uname: 2.6.17-gentoo-r4 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.12.4 app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache collision-protect distlocks metadata-transfer parallel-fetch sandbox sfperms strict test" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo/" LANG="de_DE@euro" LC_ALL="de_DE@euro" LINGUAS="de" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.informatik.rwth-aachen.de/gentoo-portage" USE="x86 3dnow 3dnowext X Xaw3d a52 alsa arts artworkextra asf audiofile avi bash-completion beagle berkdb bidi bitmap-fonts bootsplash branding bzip2 cairo cdda cddb cdparanoia cdr cli cracklib crypt css cups curl custom-cflags dbus dga directfb divx4linux dlloader dri dts dvd dvdr dvdread dvi eds emacs emboss encode esd evo exif expat fam fat fbcon ffmpeg firefox foomaticdb fortran ftp gb gcj gdbm gif gnome gpm gstreamer gtk gtk2 gtkhtml hal icq idn imagemagick imap imlib ipv6 isdnlog java javascript jikes jpeg jpeg2k ldap leim libg++ libwww lm_sensors mad maildir matroska mbox mikmod mime mmx mmxext mng mono motif mp3 mpeg mpeg2 mule nautilus ncurses nforce2 nls nocardbus nptl nptlonly nsplugin nvidia objc ogg opengl pam pcre pdf pdflib perl plotutils pmu png ppds pppd preview-latex print python qt3 qt4 quicktime readline reflection reiserfs samba sdk session slang spell spl sse ssl svg svga t1lib tcltk tcpd test theora thunderbird tiff truetype truetype-fonts type1-fonts udev usb vcd videos vorbis win32codecs wmf wxwindows xine xml xorg xosd xv xvid zlib elibc_glibc input_devices_mouse input_devices_keyboard kernel_linux linguas_de userland_GNU video_cards_radeon video_cards_vesa video_cards_fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
*poof x86* ^.^;;
ppc stable
amd64 stable.
Thanks arches, it's time to make a glsa decision. i vote yes because of the server-side DoS .
I tend to vote no.
heya sec team, holidays have finished, please vote :)
Security, please vote.
if this really is a server side DoS, then I'd vote for a glsa.
Two YES votes, then lets have a GLSA.
GLSA 200609-03 Remailed (again) to FD due to DNS failure.
