https://www.theregister.com/2021/02/05/chrome_zero_day_update/

Another JavaScript engine bug, this time a BIG one (apparently). It's apparently a 0-day "already being exploited" problem that affects all
but the newest version of chrome _AND_ (of course) NO details available,
except the CVE number it's being reported under.

"the flaw exists in how Chrome handles heap overflows in V8, Chromium's Javascript engine."

What a *BIG* surprise, JAVA SCRIPT as a SECURITY CRATER! Again.

"Google is aware of reports that an exploit for CVE-2021-21148 [the
zero-day] exists in the wild"

https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-21148

yeah not a whole lot there.

"The flaw itself, described only as 'heap buffer overflow', exists in
V8, Chromium's open-source Javascript and WebAssembly engine."

in particular a windows system would be HIGHLY vulnerable. Linux and
BSDs, not so much [it would be a LOT harder to know what kinds of binary
magic would be needed to make a buffer overflow happen]. You'd
literally need to know information about the compiler, shared libraries
in use, the OS itself, and whether or not it was built from source by
the end-user.

In particular, the knowledge of the relative location (in memory) of
callable functions, relocation tables, and their format, makes this kind
of exploit "already difficult". To make use of it you'd have to map out
the executable and exploitable pieces of code, and to call into the OS,
a pre-written function that does what you want, or the ability to read
through all of the jump tables that are in a COMPLETELY different format between POSIX systems (using ELF) and Windows (using PE).

https://en.wikipedia.org/wiki/Portable_Executable https://en.wikipedia.org/wiki/Executable_and_Linkable_Format

the bad news is that both have roughly the same weaknesses with respect
to being able to modify an executable [like a virus might] to execute
'other than originally intended' code.

https://github.com/secretsquirrel/the-backdoor-factory

but at run-time, the relocation/fixup headers aren't easily available
and require some sophisticated programming techniques to read them.
Some of the simpler ones are position-dependent, so using random "base addressing" (aka Address Space Layout Randimozation) of executables
would help to mitigate this.

https://en.wikipedia.org/wiki/Address_space_layout_randomization

Unfortunately, windows code tends to load at the preferred address, and
only supports "ASLR' when the application has been so-marked in its headers.

Linux has had a weak version of ASLR for a while now. OpenBSD was
apparently the first to offer a strong one. FreeBSD is still working on
one for version 13.0 (according to the previous link), and Android has
been requiring ASLR since version 5.

FreeBSD has, in addition to other things, the possibility of building
from source. So to leverage a memory buffer overflow you would ALSO
need to know what built it and from what source.

So I'd say that if you do NOT run an expected version of Windows, you
are probably not going to suffere from any exploits of this particular vulnerability.

This goes double for something rare, like ARM64 FreeBSD on a Raspberry
Pi. Yes, that particular config works for the Pi 3B+ but not the 4. yet.



Anyway, more to come. I bet we learn that only Windows is truly
vulnerable. I'd laugh REALLY HARD if this is true.

--
(aka 'Bombastic Bob' in case you wondered)

'Feeling with my fingers, and thinking with my brain' - me

'your story is so touching, but it sounds just like a lie'
"Straighten up and fly right"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)