Новые интересные диагностики в PVS-Studio 7.35

• Новые C и С++ диагностики
• Новые C# диагностики
• Новые Java диагностики

С релизом PVS-Studio 7.35 в анализаторе появилось много новых диагностических правил. Вас ждёт: много MISRA для C, новые Unity-диагностики для C# и покрытие OWASP Top 10 для Java и многое другое. Подробности вы сможете узнать в этой заметке.

Новые C и С++ диагностики

Как мы и писали в пресс-релизе, команда С и С++ анализатора особое внимание уделила стандарту MISRA (это вы заметите по количеству диагностик).

Но вместо разбора каждой, давайте пройдёмся по интересным. А чтобы упростить "отбор", я напомню, что у нас вышла новая книга! Это "Путеводитель C++ программиста по неопределённому поведению", своего рода путеводитель по самым тайным и экзотическим местам неопределённого поведения. Автор книги — Дмитрий Свиридкин, редактор — Андрей Карпов.

Как можно догадаться из этого предисловия, мы предлагаем пройтись по парочке диагностик, связанных с неопределённым поведением.

V2627. MISRA. Function type should not be type qualified. [Для языка C]

Начнём с первой диагностики, которая выявляет возможность неопределённого поведения.

Анализатор выявляет в коде объявление типа функции с использованием квалификаторов const, volatile, restrict или _Atomic. При использовании такого типа поведение программы не определено.

Пример кода, на котором анализатор PVS-Studio сгенерирует предупреждение:

typedef int fun_t(void);

typedef const fun_t qual_fun_t;          // <=

typedef const fun_t * ptr_to_qual_fun_t; // <=

void foo()
{
  const fun_t c_fun_t;                   // <=
  const fun_t * ptr_c_fun_t;             // <=
}

Для правильной работы программы следует убрать квалификатор const при определении типа функции.

V2631. MISRA. Pointers to variably-modified array types should not be used. [Для языка C]

Продолжаем не определяться...

В этой диагностике проблема связана с использованием указателя на массив переменной длины (VLA) в объявлениях объектов или параметров функций. Это может привести к потенциальным ошибкам, поэтому использование указателя не рекомендуется.

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

Пример кода, на котором анализатор PVS-Studio сгенерирует предупреждение:

void foo(int n, int (*a)[n])
{
  int (*b)[20] = a; // поведение не определено, пока n != 20
                    // при этом типы подразумеваются как совместимые
}

void bar(int n)
{
  int a[n];
  foo(n, &a);
}

void foobar()
{
  bar(10);
}

Функция foo принимает указатель на массив переменной длины a, размер которого определяется параметром n. Внутри функции этот указатель присваивается другому указателю b, который ожидает указатель на массив фиксированного размера в 20 элементов.

Поведение такой операции не определено до тех пор, пока n != 20.

Остальные диагностики

Как и говорили, количество новых MISRA диагностик продолжает расти, вот остальные:

V2626. MISRA C 2023 12.5. The sizeof operator should not have an operand which is a function parameter declared as 'array of type'.

V2628. MISRA C 2023 21.15. Pointer arguments to the Standard Library function 'Foo' should be pointers to qualified or unqualified versions of compatible types.

V2629. MISRA C 2023 21.16. Pointer arguments to the Standard Library function memcmp should point to either a pointer type, an essentially signed type, an essentially unsigned type, an essentially Boolean type or an essentially enum type.

V2630. MISRA C 2023 6.3. Bit field should not be declared as a member of a union.

V2632. MISRA C 2023 18.9. Object with temporary lifetime should not undergo array-to-pointer conversion.

V2633. MISRA C 2023 5.5. Identifiers should be distinct from macro names.

Вебинар: C++ и неопределённое поведение

Кстати, мы решили продолжить тему неопределённого поведения и пригласили в гости Дмитрия Свиридкина — автора книги "Путеводитель C++ программиста по неопределённому поведению" (о которой упоминали выше) поучаствовать в нашем вебинаре!

На вебинаре, который прошёл совсем недавно, мы обсудили грани, отделяющие корректный C++ код от некорректного, узнали историю написания книги, поговорили о развитии языка и его будущем. В общем, было интересно :)

Если захотите ознакомиться, то вот видео:

Новые C# диагностики

В прошлом релизе PVS-Studio 7.34 команда C# анализатора пообещала сфокусироваться на создании Unity-специфичных диагностических правил в новой версии анализатора.

Что ж, ребята не соврали! Давайте пройдёмся по некоторым из них.

V3214. Unity Engine. Using Unity API in the background thread may result in an error.

Начнём, пожалуй, с диагностики, которая является новой не только для нашего инструмента, но и для Unity, т.к. связанна с новым классом — Awaitable

Анализатор обнаружил использование свойства, метода или конструктора после вызова Awaitable.BackgroundThreadAsync, которые при выполнении в фоновом потоке могут привести к таким проблемам, как зависание или выброс исключения.

Согласно документации Unity, все API, взаимодействующие с движком, должны использоваться строго из главного потока.

Пример кода, на котором анализатор PVS-Studio сгенерирует предупреждение:

private async Awaitable LoadSceneAndDoHeavyComputation()
{
  await Awaitable.BackgroundThreadAsync();
  await SceneManager.LoadSceneAsync("MainScene");
  ....
}

public async Awaitable Update()
{
  if (....)
    await LoadSceneAndDoHeavyComputation(); 

  ....
}

При выполнении метода LoadSceneAndDoHeavyComputation вызывается Awaitable.BackgroundThreadAsync, который переносит выполнение последующего кода в рамках того же метода в фоновый поток.

Из-за этого проблемы могут возникнуть при последующем вызове SceneManager.LoadSceneAsync.

V3216. Unity Engine. Checking a field with a specific Unity Engine type for null may not work correctly due to implicit field initialization by the engine.

И ещё одна диагностика, но на этот раз про неочевидные особенности Unity движка.

Анализатор обнаружил ненадёжную проверку на null у поля, которое может быть инициализировано в инспекторе Unity.

Пример кода, на котором анализатор PVS-Studio сгенерирует предупреждение:

public class ActivateTrigger: MonoBehaviour
{
  [SerializeField]
  GameObject _target;

  private void DoActivateTrigger()
  {
     var target = _target ?? gameObject;
    ....
  }
}

В этом случае, если значение _target ещё не менялось в процессе выполнения, проверка ?? будет считать _target не равным null независимо от того, было ли указано значение поля в инспекторе Unity или нет.

Подробнее о том, почему так вышло, вы можете узнать в документации.

V3217. Possible overflow as a result of an arithmetic operation.

Специфичные диагностики — это, конечно, хорошо, но про общие мы тоже не забываем!

На этот раз анализатор обнаружил арифметическую операцию, результатом которой может стать переполнение.

Пример кода, на котором анализатор PVS-Studio сгенерирует предупреждение:

private const int _halfMaximumValue = int.MaxValue / 2;

public void Calculate(int summand)
{
    int sum;

    if (summand > _halfMaximumValue + 1)
    {
        sum = _halfMaximumValue + summand;
    }

    ....
}

В методе Calculate высчитывается сумма переданного параметра и константы. Константа равна половине от максимального значения System.Int32. Перед сложением проверяется значение параметра, чтобы избежать арифметического переполнения.

Однако в условии была допущена ошибка: в нашем случае проверяется, что summand больше, чем _halfMaximumValue + 1. Если это условие будет истинным, то при сложении гарантированно произойдёт арифметическое переполнение.

Остальные диагностики

Вы думаете, что с Unity на этом точно покончено? Не тут-то было.

Вот вам ещё пачка новых Unity-специфичных диагностик за этот релиз:

V3211. Unity Engine. The operators '?.', '??' and '??=' do not correctly handle destroyed objects derived from 'UnityEngine.Object'.

V3212. Unity Engine. Pattern matching does not correctly handle destroyed objects derived from 'UnityEngine.Object'.

V3213. Unity Engine. The 'GetComponent' method must be instantiated with a type that inherits from 'UnityEngine.Component'.

V3214. Unity Engine. Using Unity API in the background thread may result in an error.

V3215. Unity Engine. Passing a method name as a string literal into the 'StartCoroutine' is unreliable.

V3216. Unity Engine. Checking a field with a specific Unity Engine type for null may not work correctly due to implicit field initialization by the engine.

V3217. Possible overflow as a result of an arithmetic operation.

V4008. Unity Engine. Avoid using memory allocation Physics APIs in performance-sensitive context.

Новые Java диагностики

На странице истории версий для релиза PVS-Studio 7.35 можно заметить пункт, в котором говориться о Java анализаторе: "Ведётся работа по покрытию стандарта OWASP Top 10 2021 для Java анализатора. К этому релизу PVS-Studio для Java находит ошибки, соответствующие 7 категориям из 10".

Сейчас PVS-Studio для Java находит уязвимости из следующих категорий:

• A01:2021-Broken Access Control;
• A02:2021-Cryptographic Failures;
• A03:2021-Injection;
• A04:2021-Insecure Design;
• A05:2021-Security Misconfiguration;
• A07:2021-Identification and Authentication Failures;
• A09:2021-Security Logging and Monitoring Failures.

Предлагаю проверить это заявление! Давайте взглянем на соответствующие диагностики

V5310. OWASP. Possible command injection. Potentially tainted data is used to create OS command.

Анализатор обнаружил, что команда уровня операционной системы создаётся из непроверенных данных, которые были получены из внешнего источника. Это может стать причиной возникновения уязвимости command injection.

Пример кода, на котором анализатор PVS-Studio сгенерирует предупреждение:

public void doUsersCommand() throws IOException {
    Scanner sc = new Scanner(System.in);
    String command = sc.nextLine();
    Runtime.getRuntime().exec(command); 
}

Строка command приходит извне и передаётся методу exec в качестве команды уровня ОС. Из-за того, что команда перед выполнением никак не проверяется, инструкция в ней может быть абсолютно любой, в том числе вредоносной.

Кстати, у этой диагностики есть сестра — V5311. OWASP. Possible argument injection.

V5318. OWASP. Setting POSIX file permissions to 'all' or 'others' groups can lead to unintended access to files or directories.

Анализатор обнаружил, что в приложении файлам задаются свободные права доступа, а именно доступ группе others. Она относится ко всем пользователям и группам (кроме владельца ресурса). Выдача этой группе прав к ресурсу может привести к возможности несанкционированного доступа.

Пример кода, на котором анализатор PVS-Studio сгенерирует предупреждение:

public void example() throws IOException {
    Path path = Path.of("/path/to/resource");
    Files.setPosixFilePermissions(
        path, 
        PosixFilePermissions.fromString("rwxrwxrwx")
    );
}

В этом примере к ресурсу по пути path получает доступ (чтение, запись и исполнение) не только владелец, но и все остальные пользователи. Это нарушает принцип минимальных привилегий.

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

Остальные диагностики

OWASP диагностики на этом не заканчиваются! Вот ещё несколько:

V5312. OWASP. Possible XPath injection. Potentially tainted data is used to create XPath expression.

V5313. OWASP. Do not use the old versions of SSL/TLS protocols as it may cause security issues.

V5314. OWASP. Use of an outdated hash algorithm is not recommended.

V5315. OWASP. Use of an outdated cryptographic algorithm is not recommended.

V5316. OWASP. Do not use the 'HttpServletRequest.getRequestedSessionId' method because it uses a session ID provided by a client.

V5317. OWASP. Implementing a cryptographic algorithm is not advised because an attacker might break it.

V5319. OWASP. Possible log injection. Potentially tainted data is written into logs.

"Вредные советы для C++ программиста" в PDF

Теперь книга Андрея Карпова "Вредные советы для C++ программиста" доступна в PDF! В ней в юмористическом формате разбираются реальные ситуации из практики программирования на C++, которые лучше избегать.

Условия получения электронной версии книги достаточно простые: подписаться на наш дайджест статей или Telegram бот. Все подробности по ссылке.

Если вы хотите получать новости о новых релизах, можете подписаться на рассылку от команды PVS-Studio по ссылке.

Спасибо за прочтение!

Если у вас есть пожелания по статьям или вопросы, то можете отправить их в форме обратной связи. И, конечно, ждём вас в комментариях :)