Helix Gnome Installer 0.1...0.5


    Alan Cox found following.   The Helix installer contains  multiple
    locally exploitable vulnerabilities.

    1. Several  of  the  gdmify  functions  are  vulnerable to  attack
       because they use system and /tmp in unsafe manners

       A mkdir of the right path by any user prior to root running the
       Helix Installer will  blank real config  files losing parts  of
       the users system configuration.

    2. The  downloader tries  to use  a /tmp/helix_install  directory,
       which at first seems a good idea.  Unfortunately

        rc = mkdir(download_dir, 0600);
        if (rc < 0) {
                if (errno != EEXIST) {
                        error_box(g_strdup_printf("Helix GNOME Update was


       In other  words, if  I get  there first  and create  a mode 777
       directory  the  Helix  user  may  end  up installing arbitarily
       modified packages from a local attacker.

    3. When  the  user  quits  the  updater  the updating code on  the
       version inspected attempts to delete the files in the  download
       directory.  Unfortunately due to an elementary coding error  it
       deletes  each   file  in   the  download   directory  with    a
       corresponding file in /var/tmp

    Bugs 2 and 3 combine to  allow any hostile local user to  make the
    user of the Helix Updater delete arbitary files.

    There are other  potential holes in  the check_rpm code  but these
    depend on the XML  database file fetched from being
    compromised.  It would appear possible to create a remote  exploit
    based on  DNS spoofing  to feed  such a  tampered XML  file to the
    Installer but this would be an extremely tricky stunt and has  not
    been attempted.

    Oddly  enough  given  these  errors  the usual buffer overrun bugs
    appear absent.  The authors make religious use of glib safe string


    Firstly if  you have  no untrusted  users on  the machine you need
    not worry about  bugs 1-3. This  means the majority  of users need
    not  worry.   If  you  have  untrusted  users  you  should set the
    download directory rather than use  the tmp default.  A  user will
    be able  to delete  arbitary files  in the  directory you  use but
    this  can  be  a  new  empty  directory  so  this is an acceptable

    Be sure to also change the download directory in instances of  the
    updater run from cron or at.

    A new version of the Helix GNOME Updater (0.6) has been  released.
    This new  version fixes  this vulnerability  by storing downloaded
    files in /var/cache/helix-install, which is writable only by root.
    New versions of the Helix GNOME Updater are available  immediately
    from Helix  Code.   A list  of supported  distributions, platforms
    and versions can be found at

    For Caldera OpenLinux eDesktop systems:

    Just to make sure there's  no confusion about this issue;  Caldera
    doesn't ship any  Helix code with  its products.   This issue will
    only affect  you if  you have  downloaded the  installer from  the
    Helix FTP site.

    For LinuxPPC systems:

    For Linux Mandrake systems:

    For Red Hat Linux systems:

    For Solaris systems:

    For SuSE 6.3 systems:

    For SuSE 6.4 systems:

    For TurboLinux systems:

    For supported i386 systems:

    For supported PPC systems:

    For supported UltraSparc Solaris systems:

    The  go-gnome  pre-installer  has  been  updated on the main Helix
    Code  mirror  and   This  new  version  fixes  this
    vulnerability by storing files in /var/cache/helix-install,  which
    is  writable  only  by  root.   A  new  version  of  the  go-gnome
    pre-installer is  available immediately  from Helix  Code, Inc. at