Даследнікі бяспекі з кампаніі Cisco дэталі () у рэалізацыі якая прадстаўляецца ў Glibc функцыі memcpy() для 32-разраднай платформы ARMv7. Праблема выклікана некарэктнай апрацоўкай адмоўных значэнняў параметру, які вызначае памер капіяванай вобласці, з-за выкарыстання асэмблерных аптымізацый, якія маніпулююць знакавымі 32-разраднымі цэлымі лікамі. Выклік memcpy() на сістэмах ARMv7 з адмоўным памерам прыводзіць да некарэктнага параўнання значэнняў і запісы ў вобласці па-за межамі паказанага буфера.
Уразлівасць можа быць эксплуатаваная для выканання кода ў сітуацыі, калі атакавалы можа арганізаваць фармаванне адмоўнага значэння зменнай, праз якую перадаецца памер капіяваных дадзеных (напрыклад, сыход у мінус будзе пры перадачы больш 2 ГБ дадзеных, але падчас нападаў для вынахаду за межы буфера трэба перадаць як мінімум 4ГБ). Функцыя memcpy() актыўна ўжываецца ў прыкладаннях, а працэсары ARMv7 распаўсюджаныя ў аўтамабільных сістэмах, мабільных, прамысловых, спажывецкіх, камунікацыйных і ўбудавальных прыладах, якія патэнцыйна могуць стаць аб'ектамі нападаў з выкарыстаннем Bluetooth, HD Radio/DAB, USB, CAN bus, Wi- Fi і іншых вонкавых крыніц дадзеных (напрыклад, могуць быць атакаваныя даступныя па сетцы сэрвісы і прыкладанні, якія прымаюць уваходныя дадзеныя без абмежавання памеру).
У якасці прыкладу прыводзіцца стварэнне працоўнага эксплоіта для нападу на ўбудаваны ў аўтамабільныя інфармацыйныя сістэмы http-сервер, даступны праз аўтамабільную Wi-Fi сетку. Старонні атакавалы можа эксплуатаваць уразлівасць у memcpy у дадзеным серверы праз перадачу GET-запыту вельмі вялікага памеру і атрымаць root-доступ да сістэмы.
На 32-разрадных сістэмах x86 праблема не выяўляецца, бо рэалізацыя memcpy для дадзенай архітэктуры карэктна інтэрпрэтуе зменную з памерам як беззнаковое цэлае значэнне з тыпам size_t (у напісанай на асэмблеры. для ARMv7 замест size_t яно апрацоўваецца як signed integer). Выпраўленне пакуль даступна ў выглядзе , які ўвойдзе ў склад жнівеньскім абнаўленні Glibc 2.32.
Выпраўленне зводзіцца да замены выкарыстання асэмблерных інструкцый, якія аперуюць знакавымі аперандамі (bge і blt), на беззнакавыя аналогі (blo і bhs).
Праблема пакуль не ўхіленая ў (у Debian 8 не праяўляецца), , , OpenEmbedded, Tizen (выкарыстоўваецца glibc). и праблема не закранае, бо яны не падтрымліваюць 32-разрадныя сістэмы ARMv7. Android не схільны ўразлівасці, бо выкарыстоўвае ўласную рэалізацыю libc (Bionic). У па змаўчанні ў большасці зборак выкарыстоўваецца Musl, але ў рэпазітары маецца і glibc.
Крыніца: opennet.ru