Какой вывод можно сделать... последние 20 лет у людей в CS какие-то проблемы с решетками?

The issues raised in my original article about the pre-installed browser extensions are still partially present. Two extensions are relaxing the default protection provided by Content-Security-Policy even though it could have been easily avoided. One extension is requesting massive privileges, even though it doesn’t actually need them. At least they switched from jQuery to React, but they still somehow managed to end up with HTML injection vulnerabilities.

In addition, two extensions will accept messages from any Avast website – or servers pretending to be Avast websites, since HTTPS-encrypted connections aren’t being enforced. In the case of the Privacy Guard (sic!) extension, this messaging exposes users’ entire browsing information to websites willing to listen. Yes, Avast used to collect and sell that information in the past, and this issue could in principle allow them to do it again, this time in a less detectable way.

The Messaging extension is responsible for the rather invasive “onboarding” functionality of the browser, allowing an Avast web server to determine almost arbitrary rules to nag the user – or to redirect visited websites. Worse yet, access to internal browser APIs has been exposed to a number of Avast domains. Even if Avast (and all the other numerous companies involved in running these domains) are to be trusted, there is little reason to believe that such a huge attack surface can possibly be secure. So it has to be expected that other websites will also be able to abuse access to these APIs.

Ряд крупных российских девелоперов потеряли доступ к облачному решению американского разработчика систем автоматизированного проектирования (САПР) для строительства, проектирования и промышленного дизайна Autodesk BIM 360, а вместе с ним и доступ к своей проектной документации, которая там хранилась. Об этом РБК сообщили два источника среди застройщиков: Autodesk начала блокировку компаний из России, которые продолжали пользоваться ее решением, делая закупки через третьи страны или через VPN.

Факт начала блокировки РБК подтвердили президент ассоциации «Национальное объединение организаций в сфере технологий информационного моделирования» (НОТИМ), руководитель комиссии по цифровизации строительной отрасли и ЖКХ Общественного совета при Минстрое Михаил Викторов, а также директор по девелопменту компании Rariteco (девелопер клубного комплекса Quartier d’Or / «Золотой квартал») Екатерина Борисова. «Модели, которые были в зарубежном облаке у девелоперов, действительно сейчас недоступны», — заявила она.

AI-9671-backend-incorrect-number-of-parameters-in-response-when-executing-GET-workspaces-owner_id-parameters-request-with-Role-query-filter

The tag must be valid ASCII and can contain lowercase and uppercase letters, digits, underscores, periods, and hyphens. It can't start with a period or hyphen and must be no longer than 128 characters.

Southwest Airlines, the fourth largest airline in the US, is seemingly unaffected by the problematic CrowdStrike update that caused millions of computers to BSoD (Blue Screen of Death) because it used Windows 3.1. The CrowdStrike issue disrupted operations globally after a faulty update caused newer computers to freeze and stop working, with many prominent institutions, including airports and almost all US airlines, including United, Delta, and American Airlines, needing to stop flights.

Страница для отслеживания работ по данному вопросу была создана в ноябре 1999 года. Исправление, к сожалению, не успели доделать в срок для включения в недавний выпуск Thunderbird 128 ESR. Код с реализацией новой возможности написан на языке Rust.

Возможность доступа к коммитам по хэшу во всех связанных форками репозиториях вызвано тем, что GitHub в целях оптимизации и исключения дубликатов хранит вместе все объекты из основного репозитория и форков, лишь логически разделяя принадлежность коммитов. Подобное хранение позволяет просмотреть в основном репозитории любой коммит из любого форка, явно указав его хэш в URL. Например, пользователь может создать форк репозитория "/torvalds/linux" и добавить в него любой код, после чего этот код станет доступен по прямой хэш-ссылке в репозитории "/torvalds/linux". В случае удаления репозитория, если имеется хотя бы один публичных форк, данные из удалённого репозитория остаются доступны по хэшу коммита.

Предлагается три сценария, представляющих угрозу безопасности:

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

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

- Третий сценарий связан с моделью разработки проектов, которые развивают базовую открытую версию в публичном репозитории и расширенную проприетарную версию в приватном. Если компания изначально развивала проект в приватном репозитории, а затем после открытия кода проекта перевела его в разряд публичных, но продолжила разработку закрытой внутренней или расширенной версии в приватном форке, имеется возможность доступа к добавленным в приватный форк изменениям по хэшам коммитов через публичный репозиторий. При этом доступ возможен только к изменениям, добавленным в приватный форк до перевода основного репозитория в разряд публичных (хранилища приватных и публичных репозиториев разделяются, но, когда два репозитория были приватными, коммиты хранились совместно, поэтому остались в репозитории после его перевода в разряд публичных).
. . .
Подобрать хэш коммита, формируемый на базе алгоритма SHA-1 и включающий 32 символа, не реально, но оказалось, что это и не требуется. GitHub поддерживает сокращённую форму обращения к коммитам, позволяющую адресовать изменения по нескольким первым символам хэша, если отсутствуют пересечения с другими коммитами. Минимальное число символов для сокращённой адресации хэша - 4, что соответствует перебору всего 65 тысяч комбинаций (16^4). При этом перебор может и не потребоваться, так как API GitHub позволяет подключать обработчики для перехвата событий, которые используются сторонними проектами, ведущими архив с полным логом всех операций, в котором информация о хэшах коммитов остаётся и после удаления репозиториев.

До конца текущей недели скорость загрузки YouTube на стационарных компьютерах может снизиться до 40%, а к концу следующей — уже до 70%. Эта мера коснется только «десктопных» версий. Мобильную связь она пока не затронет.
. . .
Не случайно для «приведения в чувство» YouTube выбран именно летний период, когда основная масса людей находится в отпусках и пользуется для выхода в интернет именно мобильными устройствами. Деградация Youtube их никак не коснется, зато сам ресурс воочию увидит, что от уговоров — государство перешло к конкретным шагам.

int sum(int* a, int len) {
  int i, sum = 0;
  for (i = 0; i < len; i += 1) {
      sum += a[i];
  }
  return sum;
}

#!/bin/sh
set -e -u

: $((sum = i = len = a = 0))
_sum() { let a $2; let len $3
  let i; let sum
  sum=0
  i=0
  while [ $i -lt $len ] ; do
    : $((sum += _$((a + i))))
    : $((i += 1))
  done
  : $(($1 = sum))
  endlet $1 sum i len a
}

# Runtime library
# Local variables
__=0
__SP=0
let() { # $1: variable name, $2: value (optional) 
  : $((__SP += 1)) $((__$__SP=$1)) # Push
  : $(($1=${2-0}))                 # Init
}
endlet() { # $1: return variable
           # $2...: function local variables
  __ret=$1 # Don't overwrite return value
  : $((__tmp = $__ret))
  while [ $# -ge 2 ]; do
    : $(($2 = __$__SP)) $((__SP -= 1)); # Pop
    shift;
  done
  : $(($__ret=__tmp))   # Restore return value
}

Problem

Docker’s default authorization model is all-or-nothing. Users with access to the Docker daemon can execute any Docker command. For greater access control, authorization plugins (AuthZ) can be used. These plugins approve or deny requests to the Docker daemon based on authentication and command context.

In 2018, a security issue was discovered where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. Although this issue was fixed in Docker Engine v18.09.1 in January 2019, the fix was not carried forward to later versions, resulting in a regression.

Vulnerability details

AuthZ bypass and privilege escalation: An attacker could exploit a bypass using an API request with Content-Length set to 0, causing the Docker daemon to forward the request without the body to the AuthZ plugin, which might approve the request incorrectly if not set to deny by default.
Initial fix: The issue was fixed in Docker Engine v18.09.1 January 2019.
Regression: The fix was not included in Docker Engine v19.03 or newer versions. This was identified in April 2024 and patches were released for the affected versions on July 23, 2024. The issue was assigned CVE-2024-41110.

. . .

Who is impacted?
Users of Docker Engine v19.03.x and later versions who rely on authorization plugins to make access control decisions.