DR-DOS

[Tomasz Rola]

On Tue, Nov 21, 2017 at 08:15:00PM +0100, Liam Proven wrote:
> On 21 November 2017 at 19:16, Tomasz Rola <rtomek at ceti.pl> wrote:
> >
> > As of "things" mentioned above, my current understanding is, those may
> > be both active code (virri, worrmms etc), as well as Darth Vader's
> > hand reaching out from the inside of VM and manipulating bits of
> > memory on hosting machine. Chances are, I worry too much about this,
> > but I suppose Pentium does not make a good platform for running VMs,
> > only a cheap one (although it used to look like a decent one, but
> > today it is only cheap).
> 
> A file-based virus could escape _if_ the VM had access to the host
> filesystem. But mine don't, partly because it's moderately hard,
> partly because it takes a _ton_ of RAM in DOS terms.
> 
> I should devote more effort to it but it's not massively useful to me
> so I've not.
> 
> But it can't propagate if the host OS can't run DOS binaries.

Aw, not this.

This:

[

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

]

    Row hammer (also written as rowhammer) is an unintended side
    effect in dynamic random-access memory (DRAM) that causes memory
    cells to leak their charges and interact electrically between
    themselves, possibly altering the contents of nearby memory rows
    that were not addressed in the original memory access. This
    circumvention of the isolation between DRAM memory cells results
    from the high cell density in modern DRAM, and can be triggered by
    specially crafted memory access patterns that rapidly activate the
    same memory rows numerous times.[1][2][3]

    The row hammer effect has been used in some privilege escalation
    computer security exploits.[2][4][5] Different hardware-based
    techniques exist to prevent the row hammer effect from occurring,
    including required support in some processors and types of DRAM
    memory modules.

    (...) On March 9, 2015, Google's Project Zero revealed two working
    privilege escalation exploits based on the row hammer effect,
    establishing its exploitable nature on the x86-64
    architecture. One of the revealed exploits targets the Google
    Native Client (NaCl) mechanism for running a limited subset of
    x86-64 machine instructions within a sandbox,[15]:27 exploiting
    the row hammer effect to escape from the sandbox and gain the
    ability to issue system calls directly.

and

[

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

]

    In computer security, virtual machine escape is the process of
    breaking out of a virtual machine and interacting with the host
    operating system.[1] A virtual machine is a "completely isolated
    guest operating system installation within a normal host operating
    system".[2] In 2008, a vulnerability (CVE-2008-0923) in VMware
    discovered by Core Security Technologies made VM escape possible
    on VMWare Workstation 6.0.2 and 5.5.4.[3][4] A fully working
    exploit labeled Cloudburst was developed by Immunity Inc. for
    Immunity CANVAS (commercial penetration testing tool).

And even more interestingly, this (is your PC a hypervisor dreaming
that he is a PC or a real PC?):

[

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

]

    Hyperjacking is an attack in which a hacker takes malicious
    control over the hypervisor that creates the virtual environment
    within a virtual machine (VM) host.[1] The point of the attack is
    to target the operating system that is below that of the virtual
    machines so that the attacker's program can run and the
    applications on the VMs above it will be completely oblivious to
    its presence.

And this has truly amused me:

[

http://www.zdnet.com/article/minix-intels-hidden-in-chip-operating-system/

]

    Buried deep inside your computer's Intel chip is the MINIX
    operating system and a software stack, which includes networking
    and a web server. It's slow, hard to get at, and insecure as
    insecure can be.

I have no idea how practical are those attacks (please bear in mind,
MINIX inside your CPU is a feature, not a... uhm) in real life, but it
does not matter as much as the fact they have been demonstrated (if I
am to believe the net), and are going to be easier and easier to
perform as time goes by. In some cases, it does not matter what is
your machine host OS vs guest OS, but if guest OS had been carefully
crafted with code meant to escape to outside (or influence it). Like,
a floppy of DRDOS dropped online in 2016.

Oh, a bit unrelated but I have read recently that in some (all?) cases
it is possible to get hold of this MINIX stuff (and some more) by
plugging in special USB dongle... This is nothing important compared
to the above, but quite funny, so I included it here.

Basically, the idea of the above snippets is, software running in
isolated sandbox cannot be counted on staying isolated there.

[...]
> > whichever could run assembler without a
> > flop,
> 
> I don't understand that bit.

"Flop", because my very old experience with those emulators (Dosemu,
Dosbox) was such that sometimes, some software could flop, as in "To
fall, sink, or throw one's self, heavily, clumsily, and unexpectedly
on the ground." (Webster)

But I think this has been improved and I do not have to worry.

> > Emacs on native side for editing,
> 
> Euw. ;-)

Believe me, the longer it is being used, the better it seems :-).

[...]
> > There are also MenuetOS and KolibriOS, which look like nice "couldbe"
> > multiplexers for Dosbox, but I am not sure (would have to find time to
> > research) if there is any possibility to run DOS programs under their
> > control (and I could not find explicit answer in few minutes).
> 
> They're not DOS-compatible, AFAIK.

Ouch. Thanks for letting me know, it will save me some useless effort.

-- 
Regards,
Tomasz Rola

--
** A C programmer asked whether computer had Buddha's nature.      **
** As the answer, master did "rm -rif" on the programmer's home    **
** directory. And then the C programmer became enlightened...      **
**                                                                 **
** Tomasz Rola          mailto:tomasz_rola at bigfoot.com             **