[Info-vax] Android development Was Re: OT: Larry Ellison takes retirement as CEO of Oracle

[Johnny Billquist]

On 2014-09-22 01:20, David Froble wrote:
> Johnny Billquist wrote:
>> On 2014-09-21 19:13, Paul Sture wrote:
>>> On 2014-09-21, David Froble <davef at tsoft-inc.com> wrote:
>>>> Johnny Billquist wrote:
>>>>> On 2014-09-20 16:48, Paul Sture wrote:
>>>>
>>>>>> And to keep this on topic for c.o.v. VSI will have to acquaint
>>>>>> themselves with the topic of malware which runs on x64 systems.
>>>>>
>>>>> ???
>>>>> Not really. Unless it's built for VMS, it will not run (unless VMS
>>>>> suddenly starts being able to run Unix binaries, which I seriously
>>>>> doubt
>>>>> will happen).
>>>>
>>>> Well, let's think about this a bit.
>>>>
>>>> x86 has an instruction set.
>>>>
>>>> If you can get some x86 instructions into memory, and get them to start
>>>> executing, that would be an issue.
>>>
>>> Yes.  This is what the phrase "Arbitrary code execution" that you see in
>>> reports of attacks which take advantage of buffer overflows and zero day
>>> exploits.
>>>
>>> <https://en.wikipedia.org/wiki/Arbitrary_code_execution>
>>>
>>> "Most of these vulnerabilities allow the execution of *machine code*..."
>>>
>>> It doesn't necessarily mean launching a fully-fledged executable. Just
>>> finding a hole the first time round with the idea of coming back
>>> later to
>>> exploit it might be the aim.
>>>
>>> The next time the aim could simply be leaving "something" around to
>>> assist
>>> in a future and more sophisticated attack.
>>>
>>> continuing the above quoted sentence:
>>>
>>> "... and most exploits therefore inject and execute shellcode to give an
>>> attacker an easy way to manually run arbitrary commands."
>>>
>>> <https://en.wikipedia.org/wiki/Shellcode>
>>>
>>> Now that's not going to be as simple an approach on VMS processes which
>>> don't have CLI capability  but you can see where this is going.
>>>
>>>> Not saying this could be done.  Just mentioning one thing that might be
>>>> possible.
>>>>
>>>> Would also doubt that most malware would know what to do with VMS.
>>>
>>> Security by obscurity (which does work to a certain extent, but won't
>>> keep
>>> the determined and talented pro out).
>>>
>>> Until Stuxnet you wouldn't have thought that centrifuges would be a
>>> target.  The target could be something attached to a VMS system rather
>>> than VMS itself...
>>>
>>>> After the Israelies being able to tell which encryption algorithm was
>>>> running by the sounds of the power supply, I'm not sure you can say
>>>> "never" to anything ....
>>>
>>> Indeed.
>>
>> While a fun topic, we have now come back to a point where we are
>> talking about an exploit designed specifically for VMS.
>>
>> That is definitely possible, but is not more relevant when running on
>> a VAX than on an x86. If you have a piece of code designed
>> specifically to try and exploit a VMS system, I'm sure you can come up
>> with a whole bunch of potential problems, but it's not something new
>> that will happen when VMS is ported to x86.
>>
>> So the whole argument about VMS suddenly becoming much more exposed
>> because it will be running on x86 is just a red herring.
>>
>> No machine code exploits, neither for userspace, nor kernelspace, that
>> exists for other operating systems, have much of any relevance for VMS.
>>
>> VMS havae its own problems. Let's not deny that. But implying that the
>> problems will be tenfold just because it is running on an architecture
>> that is more spread is nonsense.
>>
>>     Johnny
>>
>
> I disagree.
>
> If you got x86 code running in kernel mode, it owns the system.  If it
> needs OS capabilities, then yes, it would need to know about VMS.  But
> if all it needs to do is load in it's own microkernel, and networking,
> then VMS is then totally out of the picture.  Now you've been truly hacked.
>
> Just because it doesn't understand RMS is little help at this point.

*How* do you get the x86 code running in kernel mode, without involving 
the OS at all???

	Johnny