В Сети появилось видео реального угона Tesla Model S с помощью бреши

В Сети появилось видео реального угона Tesla Model S с помощью бреши

В Сети появилось видео реального угона Tesla Model S с помощью бреши

В Сети появилось видео, на котором двое злоумышленников угоняют автомобиль Tesla Model S при помощи брелка-ключа. Это очередное напоминание, что, несмотря на всю высокую технологичность этих машин, угнать их довольно легко без должного уровня защиты.

На размещенном видеоролике мы видим, как двое мужчин ходят вокруг припаркованного Model S, дело происходит в Великобритании. Используя одновременно планшет и смартфон, преступники наконец перехватывают частоту, на которой работает брелок-ключ владельца.

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

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

Компания Tesla уже предупреждала пользователей своей продукции о возможности подобных угонов — ранее в этом году прошла волна похожих инцидентов. В Tesla даже разработали несколько специфических методов защиты, которые смогут остановить угон автомобиля.

Среди функций защиты стоит отметить анонсированную недавно «PIN to drive». Эта функция требует ввести PIN-код на сенсорном экране автомобиля, иначе он никуда не поедет.

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

О проблеме безопасности сообщила команда исследователей из Лёвенского католического университета. Эксперты пообещали опубликовать соответствующий документ на конференции Cryptographic Hardware and Embedded Systems в Амстердаме.

По словам специалистов, им удалось сломать шифрование, используемое в беспроводных брелках, используемых машинами Tesla Model S. Для успешной атаки потребуется оборудование на сумму $600.

Баги в ядре Linux скрываются в среднем 2 года, а иногда и 20 лет

История с первой CVE для Rust-кода в ядре Linux, которая недавно привела к падениям системы, выглядела почти как повод для оптимизма. В тот же день для кода на C зарегистрировали ещё 159 CVE — контраст показательный. Но новое исследование напоминает: проблема не только в языках программирования.

Гораздо тревожнее первой Linux-дыры в коде на Rust тот факт, что многие ошибки в ядре Linux могут годами, а иногда и десятилетиями оставаться незамеченными.

Исследовательница Дженни Гуанни Ку из компании Pebblebed проанализировала 125 183 бага за почти 20 лет развития ядра Linux — и результаты оказались, мягко говоря, неожиданными.

 

По данным исследования, средний баг в ядре Linux обнаруживают через 2,1 года после его появления. Но это ещё не предел. Самый «долгоиграющий» дефект — переполнение буфера в сетевом коде — прожил в ядре 20,7 года, прежде чем на него обратили внимание.

Важно уточнить: речь идёт о багах в целом, а не только об уязвимостях. Лишь 158 ошибок из всей выборки получили CVE, остальные могли приводить к сбоям, нестабильности или неопределённому поведению, но не обязательно к эксплуатации.

Исследование опирается на тег Fixes:, который используется в разработке ядра Linux. Когда разработчик исправляет ошибку, он указывает коммит, в котором баг был добавлен. Дженни написала инструмент, который прошёлся по git-истории ядра с 2005 года, сопоставил такие пары коммитов и вычислил, сколько времени баг оставался незамеченным.

В датасет вошли данные до версии Linux 6.19-rc3, охватывающие период с апреля 2005 по январь 2026 года. Всего — почти 120 тысяч уникальных исправлений от более чем 9 тысяч разработчиков.

Оказалось, что скорость обнаружения ошибок сильно зависит от подсистемы ядра:

  • CAN-драйверы — в среднем 4,2 года до обнаружения бага;
  • SCTP-стек — около 4 лет;
  • GPU-код — 1,4 года;
  • BPF — всего 1,1 года.

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

Отдельная проблема — неполные фиксы. Исследование показывает, что нередко разработчики закрывают проблему лишь частично. Например, в 2024 году был выпущен патч для проверки полей в netfilter, но уже через год исследователь нашёл способ его обойти.

Такие ситуации особенно опасны: создаётся ощущение, что проблема решена, хотя на самом деле она просто сменила форму.

RSS: Новости на портале Anti-Malware.ru