Bugzilla Bug 131010

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.