• chrome browser JAVA SCRIPT security crater

    From Big Bad Bob@21:1/5 to All on Sat Feb 6 13:48:25 2021

    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"


    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.


    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.


    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)