Buffer Overflows in Notepad++ | Hacker News Reader

Buffer Overflows in Notepad++

securitylab.github.com

68 pointslayer860 comments

In this case, there are 4 bugs. One causes N++ to write 1 to 3 bytes past the end of a buffer, the other bugs cause N++ to read some bytes past the end of heap objects, even the researchers aren't sure how they could be exploited.

While it's good they're fixed, it looks pretty much like what you get running code in a fuzzer with ASan enabled - finding obscure and very difficult to exploit memory correctness bugs. Unless a miracle happens and those 3 bytes can be made to belong to some very important structure, there's not much can be done with control of those 3 bytes.

> 2023-08-15: Notepad++ v8.5.6 without the fixes was released.

> 2023-08-21: Publishing according to our coordinated disclosure policy.

I read it as NOT fixed.

Oh, that's more concerning.

> 2023-07-17: Asked the maintainer if they successfully downloaded the binary PoC, if they have any questions and notified about the disclosure policy. No reply received.

It doesn't sound like there's a dispute over these being bugs, but the author has forgotten or ignored this issue?

But still..

* Headline: BUFFER OVERFLOWS! WRITES! (MAYBE) ARBITRARY CODE EXECUTION!

* Details: we can make it continue 1 extra cycle of a loop to write beyond a string buffer boundary. We can't make it perform arbitrary code execution but you never know.

If the string buffer abuts something important in memory (e.g. a return address on the stack), or you can manipulate things so that it does, then even 1 byte write is bad, so I wouldn't dismiss it out of hand... but it does seem like the researchers didn't find anything useful to do with their 3-byte overflow write.

Hopefully the author picks this up and fixes it.

According to the article, just opening a malicious file may lead to arbitrary code execution, no? Edit: will -> may

This seems like a very narrow case with very low risk. You would have to have UTF-16 source code of unknown providence that you decide to load up and convert to UTF-8, and that source code would have to have some hidden exploit it. How likely is this scenario, I would say close to zero.

You can't fix all of the bugs, nor should you try. You have balance bug fixing with feature development.

According to TFA, just opening the file is sufficient to trigger the buffer overflow: “Open the file in Notepad++ to hit out of bounds access with ASAN.”

Say, a *.txt file attached to an email, the opening of which in a text editor is usually considered benign.

Ideally… yes. Consider that Windows APIs use UTF-16, not UTF-8, for wide characters. Microsoft's extensions to ISO 9660 used (big endian!) UCS-2 (a.k.a. UTF-16) for long filenames, NTFS uses proper UTF-16 I believe.

You are right: NTFS exclusively runs on UCS-2, now "UTF-16 without validation". Back in the 1980s "Unicode" referred to a way to represent the ISO standard "Universal Character Set", i.e. UCS-2, instead of being synonymous to the entire character set like today. The wisdom of i18n back then was to use "Unicode" text encoding because it covered the known universe of writing. Qt made a similar choice.

I think NTFS is UCS-2, that is why WTF-8 was invented

https://simonsapin.github.io/wtf-8/

Surrogate pairs are interpreted by client software, so it’s UTF-16 in that sense. The file system just doesn’t ensure that there won’t be unpaired surrogates, or other noncharacters. This is similar to strings in .NET, Java, and JavaScript.

Which unfortunately means you can't rely on it being UTF-16.

Nor should you. Even a well-formed sequence of utf-16 codepoints can be utter nonsense; there's approximately no level of abstraction between "sequence of fixed-width code units" and "run it through a full-blown a font rendering stack" where it makes sense to assume your input is "well-formed".

Actually, you can manifest your windows app as UTF8 aware and all the win32 "-A" (formerly ascii only) APIs switch to handling UTF8 :3

This is a feature of Windows 10+ https://learn.microsoft.com/en-us/windows/apps/design/global...

Or notepad++ could just use the WinAPI (WideCharToMultiByte) to convert UTF-16 to UTF-8 instead of hand writing their own conversion routine.

There's multiple issues reported, only the first one appears to be UTF-16 related and all of the reported issues trigger the issue with simply opening a malicious text file. The referenced conversion presumably happens eagerly so the editor can operate in utf8 in memory.

I think that's more severe than you suggest; it means that someone could craft malware and all it would take is get someone to view the file in notepad++ to run an exploit.

> You can't fix all of the bugs, nor should you try. You have balance bug fixing with feature development.

Using that to justify not fixing specific critical bugs is silly.

A person reporting a CVE that allows arbitrary code execution is not saying "you should fix all the bugs", they're saying "This bug is important".

You can and should strive to fix all clearly-reported show-stopper security bugs. Which this is.

For a long time I wanted to write my own text editor, just extending SciTE to have sessions, syntax coloring, spell check and maybe a few other very basic things.

Might be time to prioritize doing so.

Edit: Not sure why this is being downvoted

I can't tell if this comment is sarcasm or not

Why would it be. Please elaborate.

I always said it: they should work more on their code, not on which kiss-up political title the next version will have.

That's disappointing. I used to use Notepad++ heavily but it seems to have really lagged behind other lightweight text editors like Visual Studio Code

I'm going back and forth between those two and find it hard to leave NP++, but I know VSCode is superior in other ways besides minimalism. If the dev has a good response to this disclosure I'll probably continue to not be in a hurry to leave it.

I also use both. Notepad++ is better for quick and dirty editing

It's hard to beat an extensible project maintained by Microsoft with a Windows C++ project written by one guy.

(I personally ditched n++ because the shell highlighting false-positives errors, and syntax errors are especially ugly in the default scheme. And it wasn't on GitHub back then, so complaining would be a chore.)

Interestingly my number #1 killer feature for N++ seems to be "having multiple unsaved files open and they are transparently saved and restored after restarting the app". In the past I've judged people who did this with a "just save your damn files" but since I, too, have converted to the ephemeral notes buffer where I don't want to find a location and file name to save it.

The funny thing is that my N++ instance has ~5 files always opened, 3-4 of those buffers and when they get to 6 or 7 I trim them down to 3-4. This is probably the beginning of why we find people doing weird things...

Been using Bear on macOS (work) and Obsidian on Linux (personal use) for that now

VS Code is not at all lightweight compared to NP++.

lightweight like vscode made me chuckle

Ok it was not just me then.

I use both. NP++ for like single documents or quick kanban lists for myself. VSCode is better for a group of closely related items such as when using it as an IDE. As I do not keep both open all the time NP++ usually wins on startup speed. Which fits my workflow.

I think they wrote "lightweight text editor" but really they meant lightweight editors, with a loose classification of full-blown IDEs as heavyweight and everything lighter as lightweight, VSCode being the heaviest in the lightweight category.

> lightweight text editors like Visual Studio Code

I wouldn't call anything based on Electron "lightweight".

My completely subjective list of text editors in order of lightweightness:

Notepad2 - a feather

Notepad++ - a dog

VS Code - an elephant

I haven't used it in a long time, but Textpad was my go-to ultra light. At the time, it only supported ASCII (no Unicode) so it only used one byte per character. I frequently had to open files that would hit 32 bit memory limits.

If VS Code is an elephant than what are VS, IntelliJ, Eclipse? Skyscrapers? Aircraft carriers?

Whales

Eclipse is a herd of cattle sellotaped together in the shape of a giant cow.

Yes. Though they don't pretend to be text editors.

IntelliJ and VS are like two different models of US aircraft carrier

Eclipse is like that one Russian aircraft carrier.

They're not text editors.

I think most people use vscode exactly like they would use IntelliJ; it's hard for me to justify that vscode is an editor but intellij isn't.

I don't have everything setup in vscode. I mostly just use it for syntax highlighting and generally use a JetBrains IDE for programming (code navigation works much better imo)

I think you can go either way with vscode similar to the whole vi vs neovim with tons of plugins

> If VS Code is an elephant than what are VS, IntelliJ, Eclipse? Skyscrapers? Aircraft carriers?

I was quite surprised, when I recently used VS for a small C project, at just how snappy it was for that project compared to VS Code for the same project.

I then compared it to VS Code for a larger C# project and it still compared very favourably in terms of responsiveness and speed.

I think a lot of people using VS Code are comparing small projects in VS Code to large projects in VS and concluding that it's VS that is the problem.

What about Vim and emacs?

I'm very fond of Notepad2, but development ceased in 2012 and the fork that I'm using, Notepad2-mod [1], had its last release in 2017. I wonder how many buffer overflows are lurking in there.

I just discovered Notepad3 [2], which appears to be a maintained fork. Screenshots look very similar to Notepad2. Gotta check it out later.

Any other forks that I should be aware of?

[1] https://github.com/XhmikosR/notepad2-mod

[2] https://www.rizonesoft.com/downloads/notepad3/

I use Notepad2-mod as well, didn't even know it wasn't maintained anymore! Thanks for mentioning Notepad3, I need to look into it.

My search for "notepad2" came up with https://github.com/zufuliu/notepad2, which sees routine changes: https://github.com/zufuliu/notepad2/commits/main

GUI applications are only as responsive as the framework allows them to be. Because Notepad2 and the later Notepad3 were built with win32, they will start the fastest. Applications with a lot of plugins will only load as fast as those plugins can be checked and loaded to prevent exceptions. Personally, I like AkelPad since it still uses a proper MDI like Visual Studio 2008.

Do you know what lightweight means?

200MB download, 500MB install. "Lightweight text editor"

There are

- text editors

- programmers text editors

- integrated development environments

- rapid application development tools

Sorted by size, reversely proportional to feature set. Basically VSCode is an overbloated #2, that isn't good enough to be #3 and is nowhere near #4.

You could've fit a full blown RAD into 500MB (Borland C++ Builder) 20 years ago.

It's 4 potential memory corruption issues in a 300kloc C/C++ code base, only one "may be critical" (without a working exploit being provided that's hard to tell). That's actually not too bad for an "unsafe" language.

> It's 4 potential memory corruption issues in a 300kloc C/C++ code base, only one "may be critical" (without a working exploit being provided that's hard to tell). That's actually not too bad for an "unsafe" language.

It's about normal.

It's also why Rust is struggling to eat into C and C++ marketshare - the class bugs it prevents has such a tiny footprint compared to all the bugs present in any given C and C++ system that it doesn't motivate the developers to spend the time Rust requires to ramp up to speed on a new language, and then use it in production.

Off-topic:

Checked out the N++ repo, and saw it's got 2.1k open issues and 7.2k closed ones, and this is from an org that seems to be just one or two devs. How's that even sustainable?

I've got zero experience in maintaining big open-source projects, but those numbers would freak me out, to say the least. Way past what I'd call manageable.

It’s just like people who have 40,000 unread emails. You just ignore the old ones.

Welcome to the reality of open source, it's a very limited few dedicated developers often supporting up hundred of thousands of users.

The answer? Just maintain the project as the hobby it started as. Open source is provided without warranty and users are more than free to use the provided binaries for their convenience as-is or learn to compile to contribute fixes.

Yeah feature creep is a crime in open source projects.

It's killed more useful projects than it's ever benefitted.

One of the worst parts as a core developer of a OSS software is when you get drive-by pull requests of large changes without that person attempting pre-discussion. Said large changes try to introduce feature creep outside what the core team of dedicated developers that will actually stick around for years want or can actually maintain.

You then end up with that drive-by pull requester spitting venom everywhere on twitter and other forums about how hostile the project is

> One of the worst parts as a core developer of a OSS software is when you get drive-by pull requests of large changes without that person attempting pre-discussion.

Depends on what you mean by "large changes". I've done drive-bys of changes, but they were, in my opinion, small changes.

(I think I'm in the credits for Lucaschess somewhere because of a 10-line change).

Ok maybe, but N++ has some great features. For example:

- Line operations (sort, remove blank lines, etc)

- Find/replace that can use either normal, {\n, \r, etc}, or regex

- Right-click to highlight a word in one colour, and then another word in another ...

One of my favourite Windows programs, along with Ditto (clipboard manager)

And they still push out releases constantly. I don't use it every day but it seems every 2nd or 3rd time I open N++ there is an update. It's truly impressive.

The number of open issues doesn't tell much about the health of the project, especially on a bare-bones bug tracker like Github.

For instance: how many of those are actual bugs versus feature requests versus just questions.

Of the actual bugs, how many of those are actually critical and need fixing?

As long as incoming tickets are looked at and prioritized, and those tickets that come out on top are fixed in a timely manner all is good.

The team also just might not close any 'stale' issues that never made it to the top of the priority queue (some projects automatically close stale tickets after 1 month of inactivity, which is arguably worse).

FWIW the PR page is in much better shape: 11 Open vs 3664 Closed.

It has a lot of users and many niche issues, they do not have to fix them all.

I fixed an issue myself that got on my nerve and was already sitting in the bugtracker for years, so they are more like helpful forum posts.

Reply on news.ycombinator.com