image

Androidtelefoons kwetsbaar voor aanval met malafide Flac-bestanden

woensdag 6 april 2022, 12:26 door Redactie, 5 reacties

Androidtelefoons zijn kwetsbaar voor aanvallen met malafide Flac-bestanden. Het openen van een dergelijk audiobestand maakt het mogelijk voor een aanvaller om willekeurige code op het toestel uit te voeren. Google heeft beveiligingsupdates voor Android uitgerold waarmee het beveiligingslek wordt verholpen.

Tijdens de patchronde van april heeft Google in totaal 44 kwetsbaarheden gerepareerd. Het gaat om beveiligingslekken in de eigen Androidcode en kwetsbaarheden in onderdelen van chipsetfabrikanten waar Android gebruik van maakt. De nu verholpen lekken in de Androidcode maken het mogelijk voor malafide apps om zonder interactie van gebruikers en zonder specifieke permissies hun rechten te verhogen. Misbruik is alleen mogelijk voor een aanvaller of app die al toegang tot een Androidtelefoon heeft.

Daarnaast zijn er ook meerdere kwetsbaarheden in onderdelen van chipfabrikant Qualcomm verholpen. Zes daarvan zijn beoordeeld als kritiek. Vijf daarvan zijn op afstand door een aanvaller te misbruiken. De grootste impact hebben twee kwetsbaarheden aangeduid als CVE-2021-35104 en CVE-2021-30341. De impact van deze lekken is op een schaal van 1 tot en 10 beoordeeld met een 9.8.

CVE-2021-35104 bevindt zich in de Qualcomm-code gebruikt voor het afspelen van audio. Bij het afspelen van een malafide Flac-bestand kan er een buffer overflow ontstaan waardoor een aanvaller code op het toestel kan uitvoeren. Een buffer overflow doet zich ook voor in het geval van CVE-2021-30341, alleen moet er dan een speciaal geprepareerd DSM-pakket naar de datamodem worden gestuurd. De Flac-kwetsbaarheid is aanwezig in 175 verschillende chipsets van Qualcomm, het lek in de datamodem raakt 119 chipsets.

Patchniveau

Google werkt met zogeheten patchniveaus, waarbij een datum het patchniveau weergeeft. Toestellen die de april-updates ontvangen zullen '2022-04-01' of '2022-04-05' als patchniveau hebben. Fabrikanten die willen dat hun toestellen dit patchniveau krijgen moeten in dit geval alle updates van het Android-bulletin van april aan hun eigen updates toevoegen, om die vervolgens onder hun gebruikers uit te rollen. De updates zijn beschikbaar gesteld voor Android 10, 11, 12 en 12L.

Fabrikanten van Androidtoestellen zijn volgens Google tenminste een maand geleden over de nu verholpen kwetsbaarheden ingelicht en hebben in die tijd updates kunnen ontwikkelen. Dat wil echter niet zeggen dat alle Androidtoestellen deze updates zullen ontvangen. Sommige toestellen worden niet meer met updates van de fabrikant ondersteund of de fabrikant brengt de updates op een later moment uit.

Reacties (5)
06-04-2022, 14:29 door Anoniem
Als ze dat niet met opzet erin hebben gemaakt weet ik het ook niet meer.
Een FLAC audio bestand speelt rauwe data zogezecht, zonder compressie.
Hoe achterlijk moet je zijn om je rauwe data niet naar de geluidskaart te sturen ?
Mij houd je niet voor de gek.
06-04-2022, 20:01 door Xavier Ohole
Door Anoniem: Als ze dat niet met opzet erin hebben gemaakt weet ik het ook niet meer.
Een FLAC audio bestand speelt rauwe data zogezecht, zonder compressie.
Hoe achterlijk moet je zijn om je rauwe data niet naar de geluidskaart te sturen ?
Mij houd je niet voor de gek.

Ik denk dat jij er gewoon geen verstand van hebt en redeneert vanuit onwetendheid. Sorry.
06-04-2022, 22:24 door Anoniem
Door Xavier Ohole:
Door Anoniem: Als ze dat niet met opzet erin hebben gemaakt weet ik het ook niet meer.
Een FLAC audio bestand speelt rauwe data zogezecht, zonder compressie.
Hoe achterlijk moet je zijn om je rauwe data niet naar de geluidskaart te sturen ?
Mij houd je niet voor de gek.

Ik denk dat jij er gewoon geen verstand van hebt en redeneert vanuit onwetendheid. Sorry.
Zelf weet ik niets over dit onderwerp, maar als iemand vindt dat de uitleg van iemand anders niet deugt, dan hoor ik graag hoe het dan wel in elkaar zit.
07-04-2022, 11:19 door Anoniem
Door Anoniem: Als ze dat niet met opzet erin hebben gemaakt weet ik het ook niet meer.
Een FLAC audio bestand speelt rauwe data zogezecht, zonder compressie.
Hoe achterlijk moet je zijn om je rauwe data niet naar de geluidskaart te sturen ?
Mij houd je niet voor de gek.

FLAC heeft lossless compressie en bestaat uit een data stream met blokken er in (headers, frames, meta data, meer). Voor afspelen moet dit uit elkaar getrokken en gedecomprimeerd worden voor dat het naar de geluidskaart kan.

CVE-2021-35104 "Possible buffer overflow due to improper parsing of headers while playing the FLAC audio clip" is dan behoorlijk slordig. Opzet lijkt mij zeer sterk.
09-04-2022, 01:57 door Anoniem
Door Anoniem: Als ze dat niet met opzet erin hebben gemaakt weet ik het ook niet meer.
Een FLAC audio bestand speelt rauwe data zogezecht, zonder compressie.
Hoe achterlijk moet je zijn om je rauwe data niet naar de geluidskaart te sturen ?
Mij houd je niet voor de gek.

Nee, het voor de gek houden van jou doe je zelf al prima , daar hoeft niemand bij te helpen .

Waarom heb je de pretentie dat je dit snapt ?
Waar haal je vandaan dat "lossless" betekent "rete simpel format zonder compressie" ?

FLAC - Free Lossless Audio Codec
Het enige wat 'lossless' zegt is dat er , in tegenstelling tot bijvoorbeeld MP3 , geen audio informatie weggegooid wordt.

De vertaling daarvan "rauwe data zonder compressie" - en de implicatie "formattering ervan is rete simpel, kun je alleen maar bewust fout doen" is door jou verzonnen.

Waarom zoek je niet eens de specificaties van .flac format op ?
Waarom leer je niet zelf programmeren - zodat je mening over hoe aannamelijk het maken van een fout is ook ergens op gebaseerd kan zijn ?

Je hebt een heel Internet waar je kunt leren en lezen hoe het echt werkt - dat is het mooie van het feit dat Flac een open formaat is .

Begin eens hier te lezen : https://xiph.org/flac/documentation_format_overview.html

Ik zal een paar citaten posten - tegen de tijd dat je snapt waar die over gaan , mag je nog een keer roepen "dat is zo simpel dat kun je alleen maar expres fout programmeren" .


BLOCKING

The block size is an important parameter to encoding. If it is too small, the frame overhead will lower the compression. If it is too large, the modeling stage of the compressor will not be able to generate an efficient model. Understanding FLAC's modeling will help you to improve compression for some kinds of input by varying the block size. In the most general case, using linear prediction on 44.1kHz audio, the optimal block size will be between 2-6 ksamples. flac defaults to a block size of 4096 in this case. Using the fast fixed predictors, a smaller block size is usually preferable because of the smaller frame header.

INTER-CHANNEL DECORRELATION

In the case of stereo input, once the data is blocked it is optionally passed through an inter-channel decorrelation stage. The left and right channels are converted to center and side channels through the following transformation: mid = (left + right) / 2, side = left - right. This is a lossless process, unlike joint stereo. For normal CD audio this can result in significant extra compression. flac has two options for this: -m always compresses both the left-right and mid-side versions of the block and takes the smallest frame, and -M, which adaptively switches between left-right and mid-side.

MODELING

In the next stage, the encoder tries to approximate the signal with a function in such a way that when the approximation is subracted, the result (called the residual, residue, or error) requires fewer bits-per-sample to encode. The function's parameters also have to be transmitted so they should not be so complex as to eat up the savings. FLAC has two methods of forming approximations: 1) fitting a simple polynomial to the signal; and 2) general linear predictive coding (LPC). I will not go into the details here, only some generalities that involve the encoding options.

First, fixed polynomial prediction (specified with -l 0) is much faster, but less accurate than LPC. The higher the maximum LPC order, the slower, but more accurate, the model will be. However, there are diminishing returns with increasing orders. Also, at some point (usually around order 9) the part of the encoder that guesses what is the best order to use will start to get it wrong and the compression will actually decrease slightly; at that point you will have to you will have to use the exhaustive search option -e to overcome this, which is significantly slower.

Second, the parameters for the fixed predictors can be transmitted in 3 bits whereas the parameters for the LPC model depend on the bits-per-sample and LPC order. This means the frame header length varies depending on the method and order you choose and can affect the optimal block size.

RESIDUAL CODING

Once the model is generated, the encoder subracts the approximation from the original signal to get the residual (error) signal. The error signal is then losslessly coded. To do this, FLAC takes advantage of the fact that the error signal generally has a Laplacian (two-sided geometric) distribution, and that there are a set of special Huffman codes called Rice codes that can be used to efficiently encode these kind of signals quickly and without needing a dictionary.

Rice coding involves finding a single parameter that matches a signal's distribution, then using that parameter to generate the codes. As the distribution changes, the optimal parameter changes, so FLAC supports a method that allows the parameter to change as needed. The residual can be broken into several contexts or partitions, each with it's own Rice parameter. flac allows you to specify how the partitioning is done with the -r option. The residual can be broken into 2^n partitions, by using the option -r n,n. The parameter n is called the partition order. Furthermore, the encoder can be made to search through m to n partition orders, taking the best one, by specifying -r m,n. Generally, the choice of n does not affect encoding speed but m,n does. The larger the difference between m and n, the more time it will take the encoder to search for the best order. The block size will also affect the optimal order.

FRAMING

An audio frame is preceded by a frame header and trailed by a frame footer. The header starts with a sync code, and contains the minimum information necessary for a decoder to play the stream, like sample rate, bits per sample, etc. It also contains the block or sample number and an 8-bit CRC of the frame header. The sync code, frame header CRC, and block/sample number allow resynchronization and seeking even in the absence of seek points. The frame footer contains a 16-bit CRC of the entire encoded frame for error detection. If the reference decoder detects a CRC error it will generate a silent block.

MISCELLANEOUS
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.