Where can they hide?

[Art]

Data can also be crafted to realize bad intent.

But it's just harmless data without the malicious code. It's code
that's malicious, not data.

Art
http://home.epix.net/~artnpeg

 

[Sol]

See the difference?

Ah yes, now I do. Thanks a great deal.

Cheers!

 

[Sol]

It was a good question. )

I appreciate that. You helped alot, and I'm grateful.

Cheers!

 

[Sol]

It was a good question. )

I appreciate that. You helped alot, and I'm grateful.

Cheers!

 

[Sol]

See the difference?

Ah yes, now I do. Thanks a great deal.

Cheers!

 

[kurt wismer]

Yes. Think of the registry as a repository of data Windows and
programs use. Think of malware as programs. They are entirely
different things. It really makes no sense to say malware resides
in the registry even though the registry might be used by the malware.
For example, a registry Run key might be set by malware to force
Windows to run the malware every time Windows starts. Is the
malware then "in the registry"? Not really. A portion of the malware
simply set a key in the registry. But the malware (program) is a
executeable file separate from the registry. You see?

i don't mean to confuse the issue or anything, but i wouldn't be so sure
that malware can't reside entirely within the registry....

take the fact that the commands contained in the Run keys actually get
executed, combine that with the fact that regedit is scriptable and i
can conceive of a Run key or set of Run keys that could assemble and
execute a script (or maybe even a binary - debug.exe is scriptable too)
that could then do damage or even re-apply itself to the registry...

further, i can easily see a Run key or set of Run keys that can use
built in tools in windows to download and execute additional malware
from the web and therefore qualify as a downloader trojan...

 

[Art]

i don't mean to confuse the issue or anything, but i wouldn't be so sure
that malware can't reside entirely within the registry....

take the fact that the commands contained in the Run keys actually get
executed, combine that with the fact that regedit is scriptable and i
can conceive of a Run key or set of Run keys that could assemble and
execute a script (or maybe even a binary - debug.exe is scriptable too)
that could then do damage or even re-apply itself to the registry...

The malware is the code that planted this (hypothetical?) stuff in the
registry and the accompanying script.

further, i can easily see a Run key or set of Run keys that can use
built in tools in windows to download and execute additional malware
from the web and therefore qualify as a downloader trojan...

Same thing as above. Whatever planted the stuff in the registry is the
malware.

Following your logic, Windows itself is malware. That line just leads
to unnecessary confusion.

Art
http://home.epix.net/~artnpeg

 

[edgewalker]

I like that (possibly) part. )

Neither code nor data is malicious, it is the ill will intent of the disseminator
of that program or data that has the malice.

But it's just harmless data without the malicious code. It's code
that's malicious, not data.

Many AV programs were found to be vulnerable to maliciously malformed
archive files that overran a buffer and corrupted memory and IIRC allowed
remote code execution. Let's just say that I removed the payload portion of
the exploit so that no code was included in the file. So now I have a naliciously
malformed archive file that corrupts memory maybe to point to "somewhere"
where "something" awaits to be interpreted as code (this "something" was
already there, maybe a data structure, and not as a result of anything I did).
Even if the memory corruption is not an overwritten return address pointer,
it could still result in damage to data or a DoS to the user of an application
and realizes my bad intent - that file is malicious data because it carries out
my bad intent.

I'm suggesting that the maliciously malformed and intentionally sent file is malware.
You seem to be suggesting that the AV software is malicious just because it has a
software flaw.

 

[edgewalker]

The malware is the code that planted this (hypothetical?) stuff in the
registry and the accompanying script.

Fact not in evidence is that such items were initially placed there by code.
Even if they were, it is not uncommon for one malware to drop another.
Kurt's suggestion has merit - aside from the ability to call code that resides
external to the registry, he shows it may be possible to use the command
interpeter with commands entirely within the registry to realize bad intent.
Program control data can be as powerful as the progam code itself.

Same thing as above. Whatever planted the stuff in the registry is the
malware.

Bollocks! It doesn't even have to be a program that planted the stuff.
It's there, it executes because the OS uses that file as program control
data.

Following your logic, Windows itself is malware. That line just leads
to unnecessary confusion.

That's the same line you follow when you suggest that it is the program
that mishandles the maliciously crafted data that is "malware" - the AV
program in my other post.

 

[Art]

I like that (possibly) part. )

Neither code nor data is malicious, it is the ill will intent of the disseminator
of that program or data that has the malice.

In practice, it's the av vendor analysts that make the judgement. Av
even warn against controversialware ... commercial programs like
keyloggers and port scanners that have legit purposes.

Many AV programs were found to be vulnerable to maliciously malformed
archive files that overran a buffer and corrupted memory and IIRC allowed
remote code execution. Let's just say that I removed the payload portion of
the exploit so that no code was included in the file. So now I have a naliciously
malformed archive file that corrupts memory maybe to point to "somewhere"
where "something" awaits to be interpreted as code (this "something" was
already there, maybe a data structure, and not as a result of anything I did).
Even if the memory corruption is not an overwritten return address pointer,
it could still result in damage to data or a DoS to the user of an application
and realizes my bad intent - that file is malicious data because it carries out
my bad intent.

I'm suggesting that the maliciously malformed and intentionally sent file is malware.

And neither data nor code.

You seem to be suggesting that the AV software is malicious just because it has a
software flaw.

Never said or implied anything of the kind.

Art
http://home.epix.net/~artnpeg

 

[Art]

Fact not in evidence is that such items were initially placed there by code.
Even if they were, it is not uncommon for one malware to drop another.
Kurt's suggestion has merit - aside from the ability to call code that resides
external to the registry, he shows it may be possible to use the command
interpeter with commands entirely within the registry to realize bad intent.
Program control data can be as powerful as the progam code itself.


Bollocks! It doesn't even have to be a program that planted the stuff.

What else?

It's there, it executes because the OS uses that file as program control
data.

If it's there it was planted by malicious code, no?

That's the same line you follow when you suggest that it is the program
that mishandles the maliciously crafted data that is "malware" - the AV
program in my other post.

Ask yourself what crafted the the data maliciously and you should
understand what I'm saying.

Art
http://home.epix.net/~artnpeg

 

[Mother's L'il Helper]

i don't mean to confuse the issue or anything, but i wouldn't be so sure
that malware can't reside entirely within the registry....

take the fact that the commands contained in the Run keys actually get
executed, combine that with the fact that regedit is scriptable and i can
conceive of a Run key or set of Run keys that could assemble and execute a
script (or maybe even a binary - debug.exe is scriptable too) that could
then do damage or even re-apply itself to the registry...

further, i can easily see a Run key or set of Run keys that can use built
in tools in windows to download and execute additional malware from the
web and therefore qualify as a downloader trojan...

--
"it's not the right time to be sober
now the idiots have taken over
spreading like a social cancer,
is there an answer?"

Kurt,
Several messages ago, I responded to David about "remember using" and
it was the C0008/5 command, now the important point is that I asked if any
code could get there if you didn't let it in <safe hex>. What I see from
your responses is that "perhaps" it could. Isn't this still part of the
boot process, and wouldn't you know that something's wrong. <been out of it
for awhile...not quite sure what's up?>

MLH

 

[Curt]

Where the sun don't shine!

Kurt,
Several messages ago, I responded to David about "remember using" and
it was the C0008/5 command, now the important point is that I asked if
any code could get there if you didn't let it in <safe hex>. What I see
from your responses is that "perhaps" it could. Isn't this still part of
the boot process, and wouldn't you know that something's wrong. <been out
of it for awhile...not quite sure what's up?>

MLH

 

[kurt wismer]

The malware is the code that planted this (hypothetical?) stuff in the
registry and the accompanying script.

no, i don't think you're following me... i can place executable (script)
code *in* the registry... that code itself can be malware...

Same thing as above. Whatever planted the stuff in the registry is the
malware.

no, whatever planted that stuff in the registry is *also* malware (a
dropper or downloader of some sort, or maybe just a *.reg file using one
of the standard social engineering filename tricks)...

Following your logic, Windows itself is malware. That line just leads
to unnecessary confusion.

i don't see how you can come to that conclusion... windows executes
commands found inside the registry - that can be exploited as easily as
sticking nasty commands in autoexec.bat...

 

[Art]

no, i don't think you're following me... i can place executable (script)
code *in* the registry... that code itself can be malware...

Well, I've never heard of that sort of thing being done or being
speculated on. If you claim it's possible I'm willing to take your
word for it. Apparently you're not aware of any known malware that
does this or you would have pointed it out.

No doubt there would be legit and useful purposes for something like
that, which makes it rather interesting.

Art

http://home.epix.net/~artnpeg

 

[kurt wismer]

Mother's L'il Helper wrote:
[snip]

Kurt,
Several messages ago, I responded to David about "remember using" and
it was the C0008/5 command, now the important point is that I asked if any
code could get there if you didn't let it in <safe hex>. What I see from
your responses is that "perhaps" it could.

technically malware can get into any writable memory... that doesn't
necessarily mean it can do anything once there...

Isn't this still part of the
boot process, and wouldn't you know that something's wrong.

executing commands in the registry is sometimes part of the boot
process, depending on the registry keys and the way you're booting...
you wouldn't necessarily know something is wrong though...

 

[kurt wismer]

Well, I've never heard of that sort of thing being done or being
speculated on. If you claim it's possible I'm willing to take your
word for it. Apparently you're not aware of any known malware that
does this or you would have pointed it out.

you're right, i haven't heard of any malware that is stored entirely in
the registry like that...

No doubt there would be legit and useful purposes for something like
that, which makes it rather interesting.

i think, what it comes down to is that the registry is not altogether
unlike a word document from a malware perspective... it is mostly data
but it can contain code and that code can get executed...

 

[edgewalker]

What else?

Maybe I put it there by editing the registry. It doesn't matter how it got there.

If it's there it was planted by malicious code, no?

Maybe, who knows!? The point is it's there. We are talking about this
hypothetical instance of malware not any previous or post instance that
may ir may not have had something to do with this one.

Ask yourself what crafted the the data maliciously and you should
understand what I'm saying.

The general run of worms and viruses are placed where they are as a result
of the previous iteration. Intitial instances of these might not have been. This
hypothetical malware should be thought of as an intitial instance (like a seed)
which is 'still' malware even though it was not necessarily placed there by a
previous instance of the same or different malware.

 

[edgewalker]

And neither data nor code.
Huh!?


Never said or implied anything of the kind.

Sure you did - you said it is the program that is malicious not the data. I
speculated on the removal of program code from the malformed (exploit)
data (+ code) so that it is now only a simple DoS attack against the AV
app or a malicious data corruption exploit. The malice is in my design and
intended use of the crafted data, and the only code involved (relatively
speaking) is in the flawed AV application.

 

[Art]

Huh!?

Weren't you talking in this instance about exploiting a vulnerability
in some av by multiply zipping a file many times? A multiply zipped
file, as such, is nether data nor code is it?

Sure you did - you said it is the program that is malicious not the data.

I dunno, what you're talking about. You had previously talked about
buffer overrun exploits and I say (said) it's the exploit code that's
the malware and not the chosen data pattern as you were claiming.
You don't do a buffer overrun exploit without exploit code do you?

Art
http://home.epix.net/~artnpeg