The OpenNET Project / Index page

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

Уязвимость в Gnome-terminal, xfce4-terminal, Terminator и других эмуляторах терминалов на базе libVTE

08.03.2012 23:37

В эмуляторах терминалов, использующих библиотеку libVTE, выявлена уязвимость, связанная с записью содержимого буфера прокрутки экрана во временный файл, размещаемый в файловой системе /tmp (/tmp/vte*). Проблеме подвержены такие приложения, как Gnome-terminal, xfce4-terminal, guake, Terminator, evilvte, lilyterm, sakura, termi. В сохраняемом буфере прокрутки фигурируют данные, отображаемые в рамках сессии.

Временный файл удаляется после создания, но остаётся возможность доступа через файловый дескриптор, который можно узнать через анализ содержимого данных о процессе в файловой системе /proc (ls -l /proc/$PPID/fd | grep deleted). Так как временный файл доступен на чтение только владельцу и суперпользователю, то интерес представляет в основном только возможность анализа остаточной информации на диске, если раздел /tmp не создан с использованием tmpfs. Записанная во временный файл информация остаётся на диске и доступна для последующего анализа в случае попадания диска в чужие руки. В частности, при продаже диска, предварительно не очищенного надлежащим образом, на носителе могут содержаться конфиденциальные данные, об утечке которых владелец может не подозревать.



  1. Главная ссылка к новости (http://seclists.org/fulldisclo...)
Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/33304-security
Ключевые слова: security, terminal, libvte
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (28) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 00:05, 09/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    тоже мне уязвимость. это фича, а не уязвимость, разработчики об этом знали.
     
     
  • 2.11, Андрей (??), 04:11, 09/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    создавая бэкдор для ...
     
     
  • 3.12, ананим (?), 04:45, 09/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    root'а?
     
     
  • 4.23, Андрей (??), 15:07, 09/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    форензиков
     

  • 1.2, Аноним (-), 00:06, 09/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    >"Проблеме подвержены такие приложения, как Gnome-terminal, xfce4-terminal, guake, Terminator, evilvte, lilyterm, sakura, termi. В сохраняемом буфере прокрутки фигурируют данные, отображаемые в рамках сессии.

    ...
    Так как временный файл доступен на чтение только владельцу и суперпользователю, то интерес представляет в основном только возможность анализа остаточной информации на диске, если раздел /tmp не создан с использованием tmpfs. Записанная во временный файл информация остаётся на диске и доступна для последующего анализа в случае попадания диска в чужие руки. В частности, при продаже диска, предварительно не очищенного надлежащим образом, на носителе могут содержаться конфиденциальные данные, об утечке которых владелец может не подозревать."

    Новость - не новость, а попытка придать "уязвимости" какую-нибудь значимость.

     
     
  • 2.17, veritas (?), 11:56, 09/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    стоит только зайти на первоисточник: http://www.climagic.com/bugreports/libvte-scrollback-written-to-disk.html и все становится ясно
     
     
  • 3.21, pavlinux (ok), 13:27, 09/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > и все становится ясно

    Чё сказать-то хотел?

     
     
  • 4.28, stalker_by (?), 17:46, 11/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Видимо он имел ввиду что стоит прочитать "Worse case scenario"
    Медицинские данные это конечно перебор, но вот содержимое конфигов на удаленных серверах почитать можно :)
     

  • 1.4, Аноним (-), 00:23, 09/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    /tmp не на tmpfs? Странные люди.

    А вообще использование общего /tmp для всех приложений - дикость и архаизм. Гораздо правильнее создавать filesystem namespace для каждого пользователя и службы, и монтировать внутри него в /tmp свою tmpfs. Тогда все (и службы, и пользователи) будут видеть в /tmp только свои файлы, без возможности доступа к чужим. Это отсекает целое семейство уязвимостей, включая сабжевую, и далеко не все дыры из этого семейства так же безобидны.

     
     
  • 2.6, ананим (?), 00:46, 09/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Да этот файл и так никто не видит.
    Как там сказано? Кроме рута и юзверя и то через /прок.
    Которые и с нэймспейсами это же смогут делать, пусть и геморойней.
    Нет смысла городить забор.

    Зыж
    Ну не публикует опеннет списки всех дырок и уязвимостей, а только (как правило) те, что исправлены в новых релизах.
    Может не стоит и начинать? Особенно с такой жёлтой.

     
     
  • 3.7, Аноним (-), 01:05, 09/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Которые и с нэймспейсами это же смогут делать, пусть и геморойней.

    Не могут. Если все сделано правильно (используются все штатные механизмы namespaces), даже если процесс в namespace имеет права рута - он все равно не сможет увидеть файлы из других namespaces.

     
     
  • 4.10, ананим (?), 03:10, 09/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    глупости.
    айноды никто пока не отменял. и если кто-то имеет права выполнять дисковые утилиты (а это минимум рут), то он всегда сможет взять то, что ему нужно.
    а сам пользователь итак всё своё видит.

    поэтому повторюсь:
    >Как там сказано? Кроме рута и юзверя и то через /прок.
    >Которые и с нэймспейсами это же смогут делать, пусть и геморойней.

    .

     
     
  • 5.26, Аноним (-), 02:05, 10/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > айноды никто пока не отменял. и если кто-то имеет права выполнять дисковые утилиты (а это минимум рут), то он всегда сможет взять то, что ему нужно.

    Вы очень слабо представляете себе, как работают namespaces.

     
     
  • 6.27, Аноним (-), 02:07, 10/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы очень слабо представляете себе, как работают namespaces.

    ... и tmpfs.

     
     
  • 7.30, ананим (?), 18:07, 11/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Вы очень слабо представляете себе, как работают namespaces.
    >... и tmpfs.

    а вот оно тут при чём?
    хотя...
    всё уже давно придумано:
    >PAM-модуль, предоставляющий пользователям индивидуальные временные каталоги /tmp/.private/$USER в рамках управления сессией или аккаунтом.

    http://www.altlinux.org/Pam_mktemp

     
  • 6.29, ананим (?), 18:06, 11/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> айноды никто пока не отменял. и если кто-то имеет права выполнять дисковые утилиты (а это минимум рут), то он всегда сможет взять то, что ему нужно.
    >Вы очень слабо представляете себе, как работают namespaces.

    да нет, я ОТЛИЧНО представляю как это работает. :D

     
  • 2.15, Aceler (ok), 11:34, 09/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых, от сабжевой уязвимости это никак не спасёт, во-вторых, загляни в свой ~/tmp/ и удивись.
     
  • 2.18, pavlinux (ok), 12:48, 09/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > А вообще использование общего /tmp для всех приложений - дикость и архаизм.

    echo TMPDIR=$HOME/tmp >> ~/.bashrc;

    Осталось абучить савременных прораммистав и юзарав
    жить по феншую The Single UNIX ® Specification,
    http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html

    ---

    $ wget http://ftp.gnome.org/pub/GNOME/sources/vte/0.21/vte-0.21.1.tar.bz2
    $ tar xf vte-0.21.1.tar.bz2;
    $ cd vte-0.21.1;
    $ find -name \*.[ch] -exec grep -i TMPDIR {} \;

    Опаньки, тишина...

    ---
    В Glib есть какой-нить аналог TMPDIR ?

     
     
  • 3.31, ананим (?), 18:09, 11/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    pam_mktemp помогут отцу русской демократии.
     

  • 1.5, Аноним (-), 00:42, 09/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > В частности, при продаже диска, предварительно не очищенного надлежащим образом, на носителе могут содержаться конфиденциальные данные, об утечке которых владелец может не подозревать.

    Не сделал перед продажей несколько проходов dd if=/dev/urandom of=/dev/sd? - сам себе злобный буратино.

     
     
  • 2.8, анонимус (??), 01:19, 09/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    shred вроде универсальней будет
     
     
  • 3.20, zomg (?), 12:58, 09/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    dban с флешки.
     
     
  • 4.25, Аноним (-), 00:14, 10/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > dban с флешки.

    dban чем-то принципиально отличается от обычного shred? Кроме фичи "стирать всё, что вижу".

     

  • 1.13, vi (?), 09:06, 09/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Это они открыли когда все повально перешли на tmpfs на /tmp ;)
     
  • 1.14, brzm (?), 10:59, 09/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сервера MySQL и PostgreSQL подвержены аналогичной уязвимости. Если не произвести затирание всего диска, то при продаже на нем могут быть обнаружены файлы в директориях /var/lib/postgresql/, /var/lib/mysql/. Т.о. произойдёт утечка данных пользователя. Проблема решается внедрением системы шифрования ФС, всем настоятельно рекомендуется обновить свои инфраструктуры! :D
     
     
  • 2.16, Aceler (ok), 11:37, 09/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это херня по сравнению с тем, что часть памяти может оказаться на диске в свопе, а там всё — пароли открытым текстом, ключи, история команд, та же tmpfs…
     
     
  • 3.22, pavlinux (ok), 13:33, 09/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Это херня по сравнению с тем, что часть памяти может оказаться на
    > диске в свопе, а там всё — пароли открытым текстом, ключи,
    > история команд, та же tmpfs…

    Это херня по сравнению с тем, что комп можно мокнуть в жидкий азот,
    быстренько выковырять оперативку и снять весь дамп.

    Ну и уж совсем херня, по сравнению с тем, чтоб вставить админу карандаш в ухо,
    и вежливо попросить распечатать все пароли и логины которые он знает.

     
  • 2.19, pavlinux (ok), 12:50, 09/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Сервера MySQL и PostgreSQL ...
    > то при продаже

    При продаже дисков от серверов, я бы тебе другую утечку устроил.

     

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



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

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