The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Уязвимости в Linux ядре, Solaris, MoinMoin и Bugzilla

02.02.2010 16:47

Несколько новых уязвимостей:

  • В Linux ядре найдена уязвимость, позволяющая вызвать крах ядра при попытке запуска на 64-разрядной системе 32-разрядного приложения с последующим вызовом из него 64-разрядной программы.
  • В драйвере e1000 из состава Linux ядра серии 2.4.x найдена уязвимость, приводящая к краху ядра при обработке специально оформленного ethernet фрейма;
  • В версии Solaris 10 для платформы x86 устранена уязвимость, дающая локальному пользователю возможность инициирования краха ядра системы через отправку специально скомпонованного UCODE_GET_VERSION IOCTL;
  • В написанном на языке Python wiki-движке MoinMoin найдена уязвимость, которой подвержены все версии начиная с 1.5.0 и заканчивая 1.9.1. Так как обновление еще не выпущено детали проявления уязвимости не сообщаются, заявлено только, что проблема отнесена к категории опасных. В качестве временного решения рекомендуется убрать упоминание любых пользователей в конфигурационной директиве "superuser";
  • В очередной серии обновлений открытой платформы для организации трекинга ошибок Bugzilla 3.0.11, 3.2.6, 3.4.5 и 3.5.3 устранено две уязвимости. Первая проблема связана с отсутствием блокировки доступа к директориям "CVS/", "contrib/", "docs/en/xml/", "t/" и файлу "old-params.txt", что позволяет злоумышленнику получить доступ к секретным данным. Вторая ошибка позволяет обойти систему ограничения доступа для групп.


Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/25258-linux
Ключевые слова: linux, solaris, moinmoin, security, bugzilla
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (10) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, anonim (?), 20:47, 02/02/2010 [ответить]  
  • +/
    А их всё больше и больше!
     
     
  • 2.2, anonimus (?), 21:23, 02/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Это только верхушка айсберга...
     
  • 2.3, guru99 (?), 22:02, 02/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    а что хотели чтобы код был идеально чисты и без дырок?
     
     
  • 3.4, Аноним (-), 00:12, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > а что хотели чтобы код был идеально чисты и без дырок?

    ага.

     
     
  • 4.5, минона (?), 02:49, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    хотите дальше.
     
     
  • 5.9, Дмитрий Телегин (?), 10:24, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>> а что хотели чтобы код был идеально чисты и без дырок?
    >>ага.
    >хотите дальше.

    Вообще-то этого реально достижимо, но для большинства критерий качества характеризуется фразой: "программа работает".

     

  • 1.6, pavlinux (ok), 05:21, 03/02/2010 [ответить]  
  • +1 +/
    > при попытке  запуска на 64-разрядной системе
    > 32-разрядного приложения с последующим вызовом
    > из него 64-разрядной программы.

    The problem seams to be located in fs/binfmt_elf.c:load_elf_binary().  
    It calls SET_PERSONALITY() prior checking that the ELF interpreter is  
    available. This in turn makes the previously 32 bit process a 64 bit  
    one which would be fine if execve() would succeed. But after the  
    SET_PERSONALITY() the open_exec() call fails (because it cannot find  
    the interpreter) and execve() almost instantly returns with an error.  
    If you now look at /proc/PID/maps you'll see, that it has the  
    vsyscall page mapped which shouldn't be. But the process is not dead  
    yet, it's still running. By now generating a segmentation fault and  
    in turn trying to generate a core dump the kernel just dies. I  
    haven't yet looked into this code but maybe you guys are much faster  
    than me and just can fix this problem :)


    А Вот сранный Гуглы Хромой именно так и может...
    По этому я его и снес нах...й, за одно GooleMap/Picasa и Gmail,
    так как он просится в /proc и ему нужен прямой доступ к сетевухе и памяти...  

    GOOGLE - ЗЛО!!!

     
     
  • 2.7, тигар (ok), 10:14, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    согласен что гугал не нужен. однако его поделия не виноваты в том что в линакс не все нормально внутрях;)
     
  • 2.8, Гентушник (?), 10:19, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >А Вот сранный Гуглы Хромой именно так и может...
    >По этому я его и снес нах...й, за одно GooleMap/Picasa и Gmail,

    А как вы снесли Gmail? Просто интересно.
    >так как он просится в /proc и ему нужен прямой доступ к сетевухе и памяти...

    А как, простите, Gmail у вас получил такие высокие привилегии?

     
     
  • 3.10, pavlinux (ok), 15:07, 03/02/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>А Вот сранный Гуглы Хромой именно так и может...
    >>По этому я его и снес нах...й, за одно GooleMap/Picasa и Gmail,
    >А как вы снесли Gmail? Просто интересно.
    >>так как он просится в /proc и ему нужен прямой доступ к сетевухе и памяти...
    >А как, простите, Gmail у вас получил такие высокие привилегии?

    У меня???? У всех!!! И под обычным юзером...

    Чё он там делает не знаю, но например в конфигурации с 2-мя и более аплинками,
    работать почти не может.

    ps ax вообще смотрели???
    Какие-то шаманские не документированные ключи

    /proc/self/exe --channel=89.432454 --channel=4345345.3453 как-то так...

    А то, что при квоте процессора для юзеров, он пожЫрает всё 100%

    А вы говорите вирусов и троянов нет!!! Вот он, большой вирус ...
    а может гугля сама Спам рассылает.


     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру