A
Art
But it's just harmless data without the malicious code. It's code
that's malicious, not data.
Art
http://home.epix.net/~artnpeg
But it's just harmless data without the malicious code. It's code
that's malicious, not data.
Art
http://home.epix.net/~artnpeg
S
Sol
Art said:
Ah yes, now I do. Thanks a great deal.
Cheers!
S
Sol
edgewalker said:It was a good question.)
I appreciate that. You helped alot, and I'm grateful.
Cheers!
S
Sol
edgewalker said:It was a good question.
I appreciate that. You helped alot, and I'm grateful.
Cheers!
S
Sol
Art said:
Ah yes, now I do. Thanks a great deal.
Cheers!
K
kurt wismer
Art said:
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...
A
Art
The malware is the code that planted this (hypothetical?) stuff in the
registry and the accompanying script.
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
E
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.
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.
)Neither code nor data is malicious, it is the ill will intent of the disseminator
of that program or data that has the malice.
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.
E
edgewalker
Art said:
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.
It's there, it executes because the OS uses that file as program control
data.
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.
A
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.
And neither data nor code.
Never said or implied anything of the kind.
Art
http://home.epix.net/~artnpeg
A
Art
What else?
If it's there it was planted by malicious code, no?
Ask yourself what crafted the the data maliciously and you should
understand what I'm saying.
Art
http://home.epix.net/~artnpeg
M
Mother's L'il Helper
kurt wismer said:
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
C
Curt
Where the sun don't shine!
Mother's L'il Helper said:
K
kurt wismer
Art said:
no, i don't think you're following me... i can place executable (script)
code *in* the registry... that code itself can be 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)...
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...
A
Art
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
K
kurt wismer
Mother's L'il Helper wrote:
[snip]
technically malware can get into any writable memory... that doesn't
necessarily mean it can do anything once there...
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...
[snip]
technically malware can get into any writable memory... that doesn't
necessarily mean it can do anything once there...
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...
K
kurt wismer
Art said:
you're right, i haven't heard of any malware that is stored entirely in
the registry like that...
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...
E
edgewalker
Art said:
Maybe I put it there by editing the registry. It doesn't matter how it got there.
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.
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.
E
edgewalker
Art said:
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.
A
Art
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?
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