Windows (all versions) Zero Day lnk vulnerability VERY serious


Recommended Posts

I have never heard someone getting affected with a malware which managed to bypass Protected Mode, let alone get affected myself. Can you give an example of a known Protected Mode exploit?

Read the article. What gets affected with this exploit is the Windows Shell, not Internet Explorer. The Windows Shell is a key component of the OS. The fact that Internet Explorer runs on Protected Mode can't do anything about it. This is the example.

Read the article. What gets affected with this exploit is the Windows Shell, not Internet Explorer. The Windows Shell is a key component of the OS. The fact that Internet Explorer runs on Protected Mode can't do anything about it. This is the example.

So, it's not a IE8 vulnerability. If users run IE8 on Windows 7 with the default settings, they are highly unlikely to get affected. They have to visit some risky websites affected by this exploit and ignore the warning message given by Windows 7, and they have to do this before Microsoft rolls out the patch. Sorry, I can't see anyone achieving this feat unless they are absolutely determined to get a malware on their machine.

He also spotted different results that varied by the version of Windows running the PC, echoing comments from other researchers that drive-by attacks using IE6, IE7, IE8 and IE9 were successful on Windows XP, but not on the newer Windows 7. "It looks like Windows 7 has some additional magic which creates a pop-up [warning], and I suspect Vista is the same," said Moore.

Read the article. What gets affected with this exploit is the Windows Shell, not Internet Explorer. The Windows Shell is a key component of the OS. The fact that Internet Explorer runs on Protected Mode can't do anything about it. This is the example.

As much as it makes me wince to actually read this level of ignorance, let alone respond to it, I'll give it a shot anyway.

The exploit may work, but its effects will be contained within Protected Mode's "sandbox", which runs at a low integrity level. So, yes, Protected Mode can do something about it. A lot, actually.

What you're describing is a privilege escalation exploit, which is completely inaccurate in this case, as it's been made clear that payloads launched via the exploit can only gain the local user's access privileges. Protected Mode relies on UAC and Windows' interface privilege isolation mechanisms to work, so if the exploit defeats Protected Mode, it'd have similarly defeated UAC as well. This is not the case.

Please, do yourself a favor, and stick to talking about Linux in future. All you accomplish whenever you run your mouth off about Windows is make it clear you have absolutely no idea what you're talking about.

What you're describing is a privilege escalation exploit, which is completely inaccurate in this case, as it's been made clear that payloads launched via the exploit can only gain the local user's access privileges.

User's access privileges. That's reassuring, meaning it only has access to the user's data. :rolleyes:

Please, do yourself a favor, and stick to talking about Linux in future. All you accomplish whenever you run your mouth off about Windows is make it clear you have absolutely no idea what you're talking about.

No I will not. And I don't think you are entitled to tell me what I can or cannot do. I also don't considered you are entitled to call me an ignorant.

For one you have no idea who I am and what are my qualifications.

User's access privileges. That's reassuring, meaning it only has access to the user's data. :rolleyes:

I'm sorry, but it looks like you insist on continuing to display your ignorance, and even doing so with a smug attitude as though it's something to be proud of. Any exploit payloads launched via IE under Protected Mode cannot destroy or modify user data, and any attempt to steal that data is easily prevented using any properly-configured two-way firewall - such as Windows Firewall.

The way I understood it is there is the webdev exploit. In that case yes, only IE6 is really in trouble because it doesn't confirm when connecting to a webdev. Now a guy figured out how to use favicon's. If this is true, it has nothing to do with Webdev.

I'm sorry, but it looks like you insist on continuing to display your ignorance, and even doing so with a smug attitude as though it's something to be proud of. Any exploit payloads launched via IE under Protected Mode cannot destroy or modify user data, and any attempt to steal that data is easily prevented using any properly-configured two-way firewall - such as Windows Firewall.

Again with the name calling. Can't your arguments stand by their validity instead of using those type of adjectives?

Are you a 13-year old?

Fact: thousands of systems are now compromised by this exploit. No firewall, no Protected Mode have been able to stop the infection.

Microsoft itself names this as a very serious vulnerability.

You on the other hand keep up with that make believe based on no facts.

This is the last time I'll be replying to your comment if you keep up with the name calling.

Where does it say that? IE6 doesn't ask you permission to connect to a WebDav share, that's why it's more serious when using that version of IE ( when the infection vector is WebDav shares ). The favicons are displayed in every browser.

You apparently didn't read that part.

You can't infect anything with just a .lnk file though. You actually have to have an external executable to run. That means that in order to run your code, you must have a way of getting the executable onto the system. Examples of that includes memory sticks, network shares, webdav, because a shortcut can point directly to a file on them.

As for favicons, I'd like to again ask for evidence of this. Steve Gibson is not a credible source of anything. An icon (which is what favicon.ico is) is a very different thing from a shortcut (.lnk). An icon is a pure data file that simply contains raw bitmap/PNG data, and I don't see what that has to do with this vulnerability (which as far as I know is not in an image decoder). I lean towards Gibson (who is not an expert on much) having misunderstood. It's also worth noting that the chances of all the browsers using the same code parse icons is slim to none. They will be using their own internal image decoder. That means that even if something were to affect IE, you could just use a different browser.

Again with the name calling. Can't your arguments stand by their validity instead of using those type of adjectives?

Are you a 13-year old?

My arguments are valid - but that doesn't change the fact that you try to put on an air of superiority as you churn out your nauseating brand of FUD, but then turn out to be so atrociously wrong that it makes people want to cringe, on simple subject matters that you could've quickly educated yourself about by spending five minutes on Google and/or Wikipedia, and then cry, whine, and bring up your imaginary qualifications when people point out the obvious.

I gave you some friendly advice to stick to talking about Linux in future, so that you don't keep embarrassing yourself. But hey, to each his own.

Fact: thousands of systems are now compromised by this exploit. No firewall, no Protected Mode have been able to stop the infection.

Microsoft itself names this as a very serious vulnerability.

And you say I play make believe? Really?? Honestly, the irony is just gushing out in bucketloads here.

Let's assume that your claim that "thousands of systems are now compromised", is true, even though the article makes no mention of it, and you don't provide a reference for this "fact". There's still so many thing wrong in that quoted paragraph above that I'm spoiled for choice where to begin. First of all, we're talking about an exploit, not an infection. Secondly, no one has claimed that firewalls and Protected Mode stop the exploit; there's a difference between an exploit and exploit payload(s). Thirdly, that firewalls and Protected Mode do nothing is completely wrong. Protected Mode prevents the malware delivered via the exploit from doing anything but steal user data, and a properly-configured firewall prevents that.

Please note the emphasis on "properly-configured". Your claim made as much sense as saying that because your car doesn't work right if you don't know how to drive it, it means cars are useless.

The only fact here is that your claim that "all Windows users should stay away from the Web, or apply the MS suggested solution that eliminates the icons" is completely and utterly wrong. And while you may have initially had the excuse of ignorance, you know better by now, and by sticking to your original claim you're turning it from an (possibly) honest mistake into a deliberate lie, which you're now trying to defend with even more and more lies.

This is the last time I'll be replying to your comment

It's what you do best anyway. Lie low for a while when proven wrong, hope the attention goes away, and strike back with the same old FUD over and over.

I have never heard someone getting affected with a malware which managed to bypass Protected Mode, let alone get affected myself. Can you give an example of a known Protected Mode exploit?

Microsoft has demonstrated bypassing PMIE at several talks. It does however require user interaction, by getting them to click a button, but that isn't necessarily very hard. It's worth noting that PMIE still has full read access to your system. It also has write access to certain namespaces and access to most Windows APIs (which can both be to manipulate other programs). The fact is that Windows was never designed to have security within a session, and that's why elevation, integrity levels, UIPI, and UAC are not security boundaries. These are all hacks that were jury rigged onto an architecture that simply wasn't designed for it, and Microsoft makes no guarantees about them even working.

While windowing does have some limited security by blocking a small amount of of messages through UIPI (mostly those that could be used for code injection), it's not much. When it comes to graphics, there is no security and anything can freely draw whatever it wants anywhere. That includes drawing penises on top of warning messages in IE. What use is a warning message if you can just change it to say something else?

That said, I'm not really aware of any such malware in the wild, and I suspect the number is low. Mostly because it's more work than needed. People will just run freeporn.exe if you ask them anyway.

What you're describing is a privilege escalation exploit, which is completely inaccurate in this case, as it's been made clear that payloads launched via the exploit can only gain the local user's access privileges. Protected Mode relies on UAC and Windows' interface privilege isolation mechanisms to work, so if the exploit defeats Protected Mode, it'd have similarly defeated UAC as well. This is not the case.

Well, it's debatable if you could really consider the hypothetical scenario privilege escalation, and a bug that affected integrity levels or elevation would not be a security bug.

Fact: thousands of systems are now compromised by this exploit. No firewall, no Protected Mode have been able to stop the infection.

There is still zero evidence that it can spread through a browser though, so PM is irrelevant. The current exploit that has infected thousands of systems certainly has nothing to do with IE.

That includes drawing penises on top of warning messages in IE. What use is a warning message if you can just change it to say something else?

I thought the point of secure desktop (ie the black background when UAC pops-up) was to prevent any program from manipulating that window and to ensure that only the keyboard / mouse can actually click it (ie no automated scripts would work)

Fact: thousands of systems are now compromised by this exploit. No firewall, no Protected Mode have been able to stop the infection.

According to the authors claim of 9000 exploits a day (I haven't been able to find any such proof on the internet, but thats besides the matter), is still pretty dam low. I mean in a month 270,000 computers will be infected and thats like what? Less than 0.5% of the total computers in the world?

Not to mention a firewall will be able to stop the attack since you can block it from sending out data. And pretty much every AV that has access to MAPP has all the technical details they need to make a relatively good signature (I know f-secure, bitdefender, and kaspersky have all updated their signature databases in order to detect this)

I thought the point of secure desktop (ie the black background when UAC pops-up) was to prevent any program from manipulating that window?

The warning messages shown by the IE broker process (the part of PMIE that runs with full rights) aren't shown on the secure desktop. They're just normal windows.

The UAC prompt you're thinking of is only shown when you elevate something from standard user to administrator (medium to high integrity.) There's no such thing for low to medium.

I lean towards Gibson (who is not an expert on much) having misunderstood. It's also worth noting that the chances of all the browsers using the same code parse icons is slim to none. They will be using their own internal image decoder. That means that even if something were to affect IE, you could just use a different browser.

Honestly I'd rather be overly worried than not worried enough.

The warning messages shown by the IE broker process (the part of PMIE that runs with full rights) aren't shown on the secure desktop. They're just normal windows.

AFAIK those windows can only be called by already-installed plugins?

If I'm correct, then your argument becomes moot anyway.

Any window shown by IE.

Given how I can't find any further information on this, I'm rather skeptical.

Besides, how would you accomplish it? IE uses a native interface instead of, say, Firefox's XUL, meaning it's impossible to manipulate the browser chrome using Javascript or CSS. Buffer overflow attacks are a possibility, but DEP and ASLR more or less shut off that avenue. So what's left?

Honestly I'd rather be overly worried than not worried enough.

I'm not going to worry about some random claim with no evidence.

Given how I can't find any further information on this, I'm rather skeptical.

Besides, how would you accomplish it? IE uses a native interface instead of, say, Firefox's XUL, meaning it's impossible to manipulate the browser chrome using Javascript or CSS. Buffer overflow attacks are a possibility, but DEP and ASLR more or less shut off that avenue. So what's left?

I don't mean to sound rude, but you aren't paying attention. The claim was that anything that exploits a bug in IE is not much of an issue because it's contained by protected mode. I explained how it's not exactly a supermax prison and what the weaknesses are. No one except you said anything about Javascript or CSS. The context was malware running in protected mode, not how it got there.

Like I said, you can manipulate anything on the screen, because graphics in Windows has no concept of security. Windows was never designed with such an architecture. It wasn't designed to have finer granularity than sessions.

I don't mean to sound rude, but you aren't paying attention. The claim was that anything that exploits a bug in IE is not much of an issue because it's contained by protected mode. I explained how it's not exactly a supermax prison and what the weaknesses are. No one except you said anything about Javascript or CSS. The context was malware running in protected mode, not how it got there.

Like I said, you can manipulate anything on the screen, because graphics in Windows has no concept of security. Windows was never designed with such an architecture. It wasn't designed to have finer granularity than sessions.

Probably not. As far as I can tell, you're describing something so vague and theoretical, without providing any examples or reference sources, that I'm not sure I understand how it translates to the real world.

Probably not. As far as I can tell, you're describing something so vague and theoretical, without providing any examples or reference sources, that I'm not sure I understand how it translates to the real world.

It's not vague at all. I don't know what you're having a hard time understanding.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Microsoft finally admits its default Windows 11 25H2, 24H2 action broke key legacy component by Sayan Sen Microsoft last week released Windows 11 KB5094126 and KB5093998 as the latest Patch Tuesday updates. Following that the company also published the accompanying dynamic updates under KB5094149, KB5095971, and KB5094156. So far the company has acknowledged two known issues that have popped up after the release which include bugged-out Office apps as well as the Recycle Bin; though there could be more at play too. Speaking of bugs and issues, Microsoft seems to have finally acknowledged a problem that probably has been around for close to a year. That's because back in July of 2025 the company made a default change to the latest Windows 11 versions, wherein it switched to JScript9Legacy on Windows 11 24H2 and later releases. Hence following the release of version 25H2 in October 2025, JScript9Legacy also remained default-enabled. As a result there has been a compatibility issue ever since then. For those wondering, by switching to JScript9Legacy Microsoft intended to improve the security of modern Windows PCs by reducing vulnerabilities tied to legacy scripting like cross-site scripting (XSS), among others. XSS exploits can allow cyber-attackers to attach malicious code onto legitimate websites and use them to execute the code when a potential victim loads such a website. Hence the new JScript9Legacy engine enforced stricter execution policies and improved object handling, which should help mitigate such attacks. Microsoft today has published a new support article detailing the problem. Neowin spotted it while browsing. The company says that JScript global definitions and execution context may fail to persist across scripts, potentially breaking older dependent apps and web-based components that relied on this legacy behavior. In the article Microsoft has confirmed that the issue stems from its move away from the older jscript9.dll engine in favor of jscript9legacy.dll. As mentioned above, while the newer engine was designed to address vulnerabilities and strengthen security it also changes how JScript handles execution context. As a result functions and definitions loaded by one script could no longer remain available to subsequent scripts once execution ended. The company notes that some applications worked correctly on earlier Windows versions because the older JScript engine automatically retained global definitions and execution state between scripts. Under the newer model though that behavior is disabled by default causing certain legacy workloads and polyfill-dependent scripts to fail. Microsoft says it addressed the problem via the KB5077241 update though the fix had not been enabled automatically in the following updates. As such admins must explicitly turn on persistent JScript execution context using a Registry setting that the tech giant shared today. The configuration can be applied to individual processes or system-wide through the FEATURE_ENABLE_PERSISTENCE registry key. The steps have been outlined below: Run the following command to create the feature control registry key: reg add "HKLM\Software\Policies\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ENABLE_PERSISTENCE" Under this key, create a new DWORD (32-bit) value. Configure the value as follows: To enable persistence for specific processes only: Set the value to 1 for each target process name. To enable persistence for all processes: Add * as the key name and set its value to 1. You can find the official support article here on Microsoft's website.
    • The possibility that milk gathers back into a glass implies that gravity can be 'reversed'.
    • VidCoder 12.20 by Razvan Serea  VidCoder is a DVD/Blu-ray ripping and video transcoding application for Windows. It uses HandBrake as its encoding engine. Calling directly into the HandBrake library gives it a more rich UI than the official HandBrake Windows GUI. VidCoder can rip DVDs but does not defeat the CSS encryption found in most commercial DVDs. You’ll need the NET 8 Desktop Runtime. If you don’t have it, VidCoder will prompt you to download and install it. The Portable version is self-contained and does not require any .NET Runtime to be installed. You do not need to install HandBrake for VidCoder to work. Feature list: Multi-threaded MP4, MKV containers Completely integrated encoding pipeline: everything is in one process and no huge intermediate temporary files H.264, H.265, MPEG-4, MPEG-2, VP8, Theora video Hardware-accelerated encoding with AMD VCE, Nvidia NVENC and Intel QuickSync AAC, MP3, Vorbis, AC3, FLAC audio encoding and AAC/AC3/MP3/DTS/DTS-HD passthrough Target bitrate, size or quality for video 2-pass encoding Decomb, detelecine, deinterlace, rotate, reflect, chroma smooth, colorspace filters Powerful batch encoding with simultaneous encodes Customizable Pickers to automatically pick audio and subtitle tracks, destination, titles and more Instant source previews Creates small encoded preview clips Pause, resume encoding VidCoder 12.20 changes: Updated HandBrake core to 1.11.2. Download: VidCoder 12.20 | 47.0 MB (Open Source) Download: Portable VidCoder 12.19 | 89.3 MB Link: VidCoder Home Page | Github | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • Too soon, I'm still not over this death!
  • Recent Achievements

    • Week One Done
      Jordan Smith earned a badge
      Week One Done
    • Reacting Well
      BizSAR earned a badge
      Reacting Well
    • First Post
      AndreaB earned a badge
      First Post
    • Week One Done
      Huge Trailer earned a badge
      Week One Done
    • Week One Done
      Classifyskilleducation earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      590
    2. 2
      +Edouard
      185
    3. 3
      PsYcHoKiLLa
      76
    4. 4
      Michael Scrip
      73
    5. 5
      Steven P.
      66
  • Tell a friend

    Love Neowin? Tell a friend!