Note that the sophos-discussed technic is in factvery powerful: you can build some code that is apparently inoccuousbecauseit doesnot contain any dangerous code, or call to dangerous OS APIs.

However, if this code can be installed so that it will be able to silently scan any download image or file, just waiting for the file that will contain some valid and encrypted signature, then this code may recognize that signature and choose to extract the relevant attack code from the data, and then run it, even if you have enabled the NX-bit that prevents data to be executed (notably the CPU stack or heap which is commonly targetted by buffer overflows).

Even though the stack or heap remains protected, the "sleeping" background listener may already have enough code to allocate an executable memory block, put the extracted data in it, and then run it. What was apparently a non dangerous image (and that may appear with some minor or nearly invisible garbage noise in the image, comparable to white noise commonly found in photographs or in image scans, or in "antialiased" pixels or sound framesmay still hide enough information to contain arbitrary code.)

The solution for this problem is that the OS should not allow writing in any executable memory fragment, should not allow executing a writable memory fragment, and the API call that changes a writable block into an executable one being contantly monitored by an antivirus looking for dangerous codeinthisdata fragment before it gets a chance to be executed. If the antivirus finds malicious code in the data block, the APIthat transforms a writable block into an executable block will return an error,and the block will remain data, possibly still writable, but not executable.

Additionally the antivirus scanner should list the process as possibly infected, and any further call to change the status of a writable block should be slowed, and the antivirus should signal an alert tothe user about the possibly infected process that should be killed (this would kill the sleeping code that infects it, such as a modified system DLL or system hook). This could be part of the heuristic engine. The suspect part of code that calls the memory status change API should be reported, in order to find and detect it.

Note that in most common applications, there are very little valid code that changes a writable memory block into an executable one. This code is typically found in avery small part of "JIT" compilers (on .net or in a JVM), or in debuggers for programmers, or in program loaders (that change the block read from disk and gives it the permission to run). This code isgenerally completely isolated within a single DLL or executable, and should be digitally signed (if not, the antivirus engine should provide its own database of verification signatures for known DLLs or executables, and the antivirus company should permanently monitor updates made available to this code by the OS or VM vendor, the simplest being that the OS or VM vendor releases this code with an embedded strong digital signature, such as Authenticode).

Unfortunately, in Windows, not all executable components are digitally signed: look at the results of the "Digital signature verifier" tool, that reports somefiles provided by Microsoft itself, notably in system drivers. There are others in fixed-size bitmap fonts used today mostly in console apps (they really are DLLs containing a resource and a normally empty code, even though they display a .FON extension, and so they can contain code executed at DLL load and unload time and when the DLL is attached and detached to a process)

Notably, look into the Windows Devices Manager: most of them depend on hardware andarenot present in lots of PC, however some are constantandavailable on almost all of them, notably in the "hidden" (non Plug&Play) devices list that isused for system services: critical ones are "AFD", "HTTP", "TCP/IP protocol", "IpNat", "IpFilterDriver", or other filesystem drivers (NTFS, FAT, CDFS...) but some other are just there for devices rarely used and generally not considered dangerous such as "Serial" that manages serial COM ports, "Beep" that just performs horrible monophonic beeps to the PC speaker without any audio device, or "Null" that implements a silent/sink device (and matches the "NUL" filename). If any of those devices, that are loaded by default and given access to the kernel, are infected, they may perform arbitrary code. Most drivers work by installing system hooks for the Win32 APIs they wish to implement.

All these executable files (and notably the .SYS drivers andthe OS loader, because they are loaded very soon during boot time, before the antivirus loads, and because their files are NOT protected and NOT locked during OS execution) should be digitally signed, and their normal location stored in the registry should be protected (unfortunately, it's easy to remove the ACL protections from the critical parts of the registry: you can do it manually from any administrator account even if those ACLs normally do not include "Administrators" rights, only "SYSTEM" rights, where only Microsoft can authenticate as "SYSTEM" because SYSTEM protects your Windows licence). Unfortunately, they are not... and their location and filename on disk is constant, making them easy to attack if there's noantivirus to protect you from silent additions or changes in the list of system devices (Windows informs you only with PnP devices).

Nice explainations (albeit long). But the problem is usually not in the specification of a certain protocol, but in the implementation. As in the case of the JPEG rendering flaw, it was the microsoft code which allowed the vulnerability, not in the specification of how to render JPEG images.

ultracross, it would suit you very well to accept that you were wrong. From what you write I get the strange idea that you do not even understand your own words.

You write this:
"it was the microsoft code which allowed the vulnerability"

and at the same time you claim it's impossible to get infected through pictures? Please explain what's the effective difference? The effect is exactly the same. Actually this is even more dangerous as it's very hard to protect yourself against it. Just being smart won't help.
Such flaws are of course more severe by magnitudes if they exist in Microsoft products because that's what virtually everybody uses nowadays.

There's no point in bashing Microsoft here. Such flaws exist in all kinds of software and
not just software for Windows. Software for Linux, Mac OS etc. has often the same kind of vulnerabilities. I suggest
you read bugtraq for a while:

http://www.securityfocus.com/archive/1

It is somehow ironic that just a moment after my first reply,
the now well-known WMF bug was discovered or rather published. There is really no reason to call the average user a "dumbass". With these kind of bugs the user does not have to do anything "wrong".

I beg you, ultracross and others, stop spreading your *dangerous* smattering. Finally, for those who think they can clean their systems from worms and viruses on-the-fly using some tool, read this:

http://www.microsoft.com/technet/com...mt/sm0504.mspx

Even Microsoft is smart enough to comprehend this.

@Hyper-kun
And who the hell are you to say that I was wrong? It WAS a microsoft flaw. Their implementation of the JPEG specification WAS written poorly which introduced this vulnerability. If microsoft would build to suite specifications instead of what they think would be better (e.g. MSIE), they would be a better software company.

Stop being such a lamer. Who are you, a Microsoft PR agent? Its a good practice aswell as etiquette not to start **** in threads that you know nothing about.

It should be obvious that I'm neither a lamer nor a Microsoft PR agent. I also doubt that Microsoft needs your advice and that you know any kind of etiquette. You should probably improve your reading skills. I never claimed that there was no bug in code by Microsoft handling JPEG images. By the way, I know damn well what I am talking about.

I'll explain it a little simpler for you:

I wrote: "Hell you can even get virus from pictures."

You claimed: "No you can't."

That's what I referred to when I said "you are wrong". I repeat: You can infect your system through any kind of file including pictures. All it takes is an exploitable flaw in applications handling these files. Actually it doesn't require files at all. It is possible to infect a system by any kind of input as long as there is an exploitable bug in the implementation handling this input.

You wrote: "You are reffering to a Microsoft Windows flaw in the JPEG engine that is used to render JPEG images."

You are wrong again. There are far more bugs than this one. I was not thinking of any certain bug. And just to repeat myself, this problem is not unique to Windows. Windows and software for it is just the easier bait due to its popularity. Nonetheless there are inherent design flaws in Windows which make these issues a little worse than they are on other systems.

If you want me to provide an (incomplete) list of software that is exploitable I could do that. It's probably not wort the time. You can just read Bugtraq yourself:

http://securityfocus.com/archive/1

For example, the famous WMF exploit works fine for a lot of standard picture filename extensions including "jpg" and "jpeg". You just have to rename the WMF file. This might be misleading though because you probably argue that this isn't a JPEG file. WMF is still a picture format nonetheless.

Last but not least, for most users you don't have to be that smart at all since they will fall for "whatever.jpg.exe" because - nobody knows why - Windows hides known filename extensions by default. For the common user this makes it impossible to differ between a mere data file and an executable file.

In any case it's not as simple as "executables are dangerous but data files are harmless".

after phillipe posted, i pretty much gave into his explanation, quietly though. why am i even bothering to reply to you,.. oh yes, im subscribed to this thread...

*unsubscribes*

peace! im out.

*walks away all cool*

(and yes, i am always this stubborn. especially when people rub sh!t in. because then its just stupidity that propells them to further escalate something into a flame war.)

Hyper-kun Is Right
 

Hyper-kun is right you can exploit any file written

When we were flooding the networks with corrupt Mp3, wmv, wma exct

See my other posts

we created certain code in the files that when the person trying to run them (your computer slows down as it does certain things) the files were actually writing certain other files in the windows/system32 directory (as an example)

this was done on unix, linux, windows, the mac system exct

These files were also made to scan your hard drives for P2P and any d/l program you had on your computer ie Gozilla (I Know it's old, but it's an example)

The old kazaa system was flooded by fake files ie mp3, windows media files, jpg, html, exct (see my other posts) And is now considred nearly dead

the winmx system is also considered nearly dead

bearshare is under attack now

and as I have already stated they are now starting to attack this network

If u want to spot the fakes (I have already posted how) not 100%, but near enough

Read The Posts How

Sorry can't tell you what files, and how to stop them (would be sued)

But I Can Tell You This

Any File Out There is Usable

Sgt

:rolleyes:

WT*
Explanation would be nice. Sued by a company you no longer work for? Being constructive would be to give examples of such & some answers. Otherwise it sounds like heresay.:D

Hey lord
 

Hows it going

The reason I can't tell you which comp ect is, it was in the contract I signed

What I can tell you is this

it was a company that likes music

:cool:

Sgt