Live data from Hacker News

Windows Notepad App Remote Code Execution Vulnerability

cve.org

301–310 of 538 posts

Re: Windows Notepad App Remote Code Execution Vulnerability

#302
post #277

Earlier quoted context omitted.

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…

> Except no, we don't. notepad.exe was DONE SOFTWARE While 8.8 score is embarrassing, by no measure notepad was done software. It couldn't load a large text file for one, its search was barely functional, had funky issues with encoding, etc. Notepad++ is closer to what should be expected from an OS basic text editor

notepad.exe worked just fine.

Notepad++ is a monster software.

Re: Windows Notepad App Remote Code Execution Vulnerability

#303

Earlier quoted context omitted.

Unpopular opinion: rudimentary Markdown support is not entirely far-fetched even for a dumb text editor. Even though I’m all against feature bloat, I think that making Markdown hyperlinks clickable is still within the Overton window of what a simple editor should be doing.

Maybe I don't understand what markdown support will imply, but doesn't this hide text? Like, if I have a h2 or url, its going to show as special text rather than the h2 tag?

There's a toggle in the status bar and the View menu that switches between displaying Markdown as formatted vs. plain text

Re: Windows Notepad App Remote Code Execution Vulnerability

#304
post #166

Earlier quoted context omitted.

> At some point, they need to stop asking "can we add this feature?" and start asking "does this text editor need a network-aware rendering stack?" They didn’t stop there. They also asked “does this need AI?” and came up with the wrong answer.

It’s just resumé driven development. Corporate droids gotta justify their salaries somehow. It doesn’t pay to call software “done”.

Individual developers or even developer management doesn't get much of a say in product direction at large corporations. The product management folks are who decide what features go in and when.

Re: Windows Notepad App Remote Code Execution Vulnerability

#305
post #7

"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." I didn't even know Notepad would render Markdown.

Notepad rendering other formats removes one of the specific reasons I use notepad: to strip the stupid formatting that all sorts of applications seem to want to attach to text these days. Notepad handily strips away all the custom link namings and formats that totally fuck the expected output of a simple copy and paste. That's a big part of the its magic: it's immunity to the choices of marketing teams and dud manage…

Windows now has buttons in win-v (the clipboard helper popup) for this

Re: Windows Notepad App Remote Code Execution Vulnerability

#306

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…

It'd be more hilarious if it weren't so sad. In just 10 years a disturbingly large number of huge development teams decided that making a GUI application using the old ways [1] was too hard and decided to ship an entire web engine (electron) to render 10 buttons.

[1] (native GUI widgets? agggh)

Re: Windows Notepad App Remote Code Execution Vulnerability

#307
post #298
post #277

Earlier quoted context omitted.

> Except no, we don't. notepad.exe was DONE SOFTWARE While 8.8 score is embarrassing, by no measure notepad was done software. It couldn't load a large text file for one, its search was barely functional, had funky issues with encoding, etc. Notepad++ is closer to what should be expected from an OS basic text editor

What counts as "large"? I'm pretty sure at some point in my life I'd opened the entirety of Moby Dick in Notepad. Unless you want to look for text in a binary file (which Notepad definitely isn't for) I doubt you'll run into that problem too often. Also, I hope the irony of you citing Notepad++ [1] as what Notepad should aim to be isn't lost on you. My point being, these kinds of vulnerabilities shouldn't exist in a…

> What counts as "large"?

Remote into a machine that you're not allowed to copy data out of. You only have the utilities baked into Windows and whatever the validated CI/CD process put there. You need to open a log file that has ballooned to at least several hundred megabytes, maybe more.

Moby Dick is about 1MB of text. That's really not much compared to a lot of log files on pretty hot servers.

I do agree though, if we're going to be complaining about how a text editor could have security issues and pointing to Notepad++ as an example otherwise, its had its own share of notable vulnerabilities even before this update hijacking. CVE-2017-8803 had a code execution vulnerability on just opening a malicious file, this at least requires you to click the rendered link in a markdown file.

Re: Windows Notepad App Remote Code Execution Vulnerability

#308

Earlier quoted context omitted.

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…

> FIPS-compliant bindings (OpenSSL) Using FIPS mode can be insecure because the latest FIPS-compliant version can be years older than the latest non-FIPS one with all the updates. The only time it makes sense to use the FIPS version is where there is a legal or contractual requirement that trumps security considerations.

While I think this is good advice, the fact that it's true feels backward to me. "We have a legal or contractual obligation to be less secure than we otherwise would be." Just seems silly.

Re: Windows Notepad App Remote Code Execution Vulnerability

#309

Earlier quoted context omitted.

Maybe I don't understand what markdown support will imply, but doesn't this hide text? Like, if I have a h2 or url, its going to show as special text rather than the h2 tag?

There's a toggle in the status bar and the View menu that switches between displaying Markdown as formatted vs. plain text

Oh that's not so bad.

I mean... other than it creating vulnerability... and maybe is the beginning of the end of notepad as a plain text editor...

Re: Windows Notepad App Remote Code Execution Vulnerability

#310
post #299

Earlier quoted context omitted.

Unpopular opinion: rudimentary Markdown support is not entirely far-fetched even for a dumb text editor. Even though I’m all against feature bloat, I think that making Markdown hyperlinks clickable is still within the Overton window of what a simple editor should be doing.

The main problem with "Markdown support" in Notepad is that "Markdown support" is an ill-defined phrase. The closest thing to a well-defined definition is to support CommonMark but that is far, far from universal. Microsoft being Microsoft they'd probably still half-ass the job then just declare their new half-ass support a newly embraced-and-extended standard and leave it that way for the next 20 years, so asking No…

I might be dumb, but I thought the whole point of markdown was to get rid of all the bells and whistles of styling, having a really simplified and dumb format that only outlines structure. The follow-on being that many tools could parse, transform and render said markdown files in a way that makes sense for them. That way there's lots of tools that don't share code, but a shared definition of the format. I.e. markdown is a format (!?).

The problem is that overall we seem to have fumbled both the concept and the implementation. There a bunch of vaguely similar but incompatible markdowns and apparently rendering them is too hard and people immediately reach for an enormous pile of software (usually a web stack) to render it for them.

It should have been entirely possible for a person to write a markdown parser in a couple hours and e.g. render paragraphs, bulleted lists and tables into a terminal.

Post reply on HN