Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows Notepad App Remote Code Execution Vulnerability

cve.org

Post reply on HN
Print view View original

181–190 of 538 posts

Re: Windows Notepad App Remote Code Execution Vulnerability

#181

Post by iugtmkbdfil834 »

AnonymousPlanet wrote: post #54
Fiveplus wrote: post #14

We have officially reached the logical conclusion of the feature-bloat-to-vulnerability pipeline. For nearly thirty years, notepad.exe was the gold standard for a "dumb" utility which was a simple, win32-backed buffer for strings that did exactly one thing...display text. An 8.8 CVSS on a utility meant for viewing data is a fundamental failure of the principle of least privilege. At some point, they need to stop aski…

I'm not sure if we should use "gold standard" together with the little piece of garbage that notepad.exe was for most of its existence. It has been the bane for anyone who had to do work on locked down Windows servers and had to, e.g., edit files with modern encodings. They fixed some of it in the meantime, but the bitter taste remains.

You do have a point, because it shows an unfortunate inflation in words. That said, on a fresh windows install, notepad was usually an island of stability in a sea of sorrow. The day I saw AI introduced to it, I knew the end is nigh.

Re: Windows Notepad App Remote Code Execution Vulnerability

#182

Post by BLKNSLVR »

mjmas wrote: post #134

It is to do with link handling: https://msrc.microsoft.com/update-guide/vulnerability/CVE-20... > An attacker could trick a user into clicking a malicious link inside a Markdown file opened in Notepad, causing the application to launch unverified protocols that load and execute remote files.

> It is to do with link handling:

Notepad? Link handling?

That's like my pencil having a CVE that's to do with how it loads the ink. That old saying about 'if Microsoft built a car' is more true now than it was then: https://www.snopes.com/fact-check/car-balk/

Re: Windows Notepad App Remote Code Execution Vulnerability

#183

Post by fhd2 »

LiamPowell wrote: post #129
fhd2 wrote: post #119

Earlier quoted context omitted.

> Anyway, it's not related to CoPilot, but because Notepad makes links clickable now... True, not related to CoPilot, but if I understand your conclusion right (which I'm not sure about), it's not _just_ that links are clickable now, it's because Notepad actually does something with the links. Otherwise it'd be a browser vulnerability, and Notepad couldn't seriously be blamed.

It's in fact the opposite. Browsers show a popup that asks if you really intended to click a link with a non http/https handler, notepad does not. The actual RCE here would be in some other application that registers a URL handler. Java used to ship one that was literally designed to run arbitrary code.

Ah, got it. Very different from where I suspected the issue then.

Re: Windows Notepad App Remote Code Execution Vulnerability

#184

Post by usrbinbash »

weinzierl wrote: post #59
Fiveplus wrote: post #14

We have officially reached the logical conclusion of the feature-bloat-to-vulnerability pipeline. For nearly thirty years, notepad.exe was the gold standard for a "dumb" utility which was a simple, win32-backed buffer for strings that did exactly one thing...display text. An 8.8 CVSS on a utility meant for viewing data is a fundamental failure of the principle of least privilege. At some point, they need to stop aski…

"For nearly thirty years, notepad.exe was the gold standard for a "dumb" utility which was a simple, win32-backed buffer for strings that did exactly one thing...display text." Well, except that this did not prevent it from having embarrassing bugs. Google "Bush hid the facts" for an example. I'm serious, you won't be disappointed. I think complexity is relative. At the time of the "Bush hid the facts" bug, nailing d…

As funny as the "Bush hid the facts" bug may be, there is a world of difference between an embarassing mistake by a function that guesses the text encoding wrong, and a goddamn remote code execution with an 8.8 score

> and we have other battles we fight.

Except no, we don't. notepad.exe was DONE SOFTWARE. It was feature complete. It didn't have to change. This is not a battle that needed fighting, this was hitting a brick wall with ones fist for no good reason, and then complaining about the resulting pain.

Re: Windows Notepad App Remote Code Execution Vulnerability

#185

Post by josephg »

dspillett wrote: post #159
weinzierl wrote: post #59

Earlier quoted context omitted.

"For nearly thirty years, notepad.exe was the gold standard for a "dumb" utility which was a simple, win32-backed buffer for strings that did exactly one thing...display text." Well, except that this did not prevent it from having embarrassing bugs. Google "Bush hid the facts" for an example. I'm serious, you won't be disappointed. I think complexity is relative. At the time of the "Bush hid the facts" bug, nailing d…

> nailing down Unicode and text encodings was still considered rocket science. Now this is a solved problem I wish… Detecting text encoding is only easy if all you need to contend with is UTF16-with-BOM, UTF8-with-BOM, UTF8-without-BOM, and plain ASCII (which is effectively also UTF8). As soon as you might see UTF16 or UCS without a BOM, or 8-bit codepages other than plain ASCII (many apps/libs assume that these are…

> to get Excel to correctly load a UTF8 encoded CSV or similar you must include the BOM

Ah so that’s the trick! I’ve run into this problem a bunch of times in the wild, where some script emits csv which works on the developers machine but fails strangely with real world data.

Good to know there’s a simple solution. I hope I remember your comment next time I see this!

Re: Windows Notepad App Remote Code Execution Vulnerability

#186

Post by ganzsz »

autoexec wrote: post #141
TZubiri wrote: post #136

Earlier quoted context omitted.

EDIT: THE OLD NOTEPAD IS STILL IN WINDOWS AND WE CAN USE IT! https://learn.microsoft.com/en-us/answers/questions/3845356/... You basically have to find the "execution alias" setting and disable notepad and you get the ole reliable :D OLD POST: This has hurt me specifically. Since I work without IDEs, no VIM, no vs code. On linux I use nano, on windows I use Notepad. I like the minimalism and the fact that I have abso…

EDIT.COM still works in dosbox

Edit is ported to win11 and edit(.exe) should work in your shell of choice.

https://learn.microsoft.com/en-us/windows/edit/

Re: Windows Notepad App Remote Code Execution Vulnerability

#187

Post by usrbinbash »

keepamovin wrote: post #67
Fiveplus wrote: post #14

We have officially reached the logical conclusion of the feature-bloat-to-vulnerability pipeline. For nearly thirty years, notepad.exe was the gold standard for a "dumb" utility which was a simple, win32-backed buffer for strings that did exactly one thing...display text. An 8.8 CVSS on a utility meant for viewing data is a fundamental failure of the principle of least privilege. At some point, they need to stop aski…

I couldn't agree more. A text editor exposing an attack surface via a network stack is precisely the kind of bloat that makes modern computing ultra-fragile. I actually built a "dumb" alternative in Rust last week specifically to escape this. It’s a local-only binary—no network permissions, encrypted at rest, and uses FIPS-compliant bindings (OpenSSL) just to keep the crypto boring and standard. It’s inspectable if y…

Why does my text-editor need to do "encryption at rest"? If I want data encrypted, I store it in an encrypted drive with a transparent en/decryption layer.

Re: Windows Notepad App Remote Code Execution Vulnerability

#188

Post by [deleted] »

Vinnl wrote: post #87
weinzierl wrote: post #59

Earlier quoted context omitted.

"For nearly thirty years, notepad.exe was the gold standard for a "dumb" utility which was a simple, win32-backed buffer for strings that did exactly one thing...display text." Well, except that this did not prevent it from having embarrassing bugs. Google "Bush hid the facts" for an example. I'm serious, you won't be disappointed. I think complexity is relative. At the time of the "Bush hid the facts" bug, nailing d…

https://en.wikipedia.org/wiki/Bush_hid_the_facts

[deleted]

Re: Windows Notepad App Remote Code Execution Vulnerability

#189

Post by hsbauauvhabzb »

SomeUserName432 wrote: post #75
TonyTrapp wrote: post #38

Earlier quoted context omitted.

Win9x Notepad in particular can only load files up to 64KB in size (edit: and supports only ANSI encoding, no Unicode). There were some actually useful additions to it up until Windows 10 or so - for example being able to handle LF (in addition to CRLF) line endings. But yeah, everything added in Windows 11 is just pure bloat.

I find notepad useful for sanitising clipboard content. No bold text, italics, bullet points, invisible html.. Just get the text and can copy it to paste again somewhere else. Ala Cmd+Shift+V on Mac

Win+r, ctrl+v, ctrl+a, ctrl+x, esc does this without spawning a non ephemeral window

Re: Windows Notepad App Remote Code Execution Vulnerability

#190

Post by addhochohoc »

Fiveplus wrote: post #14

We have officially reached the logical conclusion of the feature-bloat-to-vulnerability pipeline. For nearly thirty years, notepad.exe was the gold standard for a "dumb" utility which was a simple, win32-backed buffer for strings that did exactly one thing...display text. An 8.8 CVSS on a utility meant for viewing data is a fundamental failure of the principle of least privilege. At some point, they need to stop aski…

You goto go with the times man, goto write yourself a fulltime job with a legacy.
Post reply on HN