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-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?
* 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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
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.
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.
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...
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 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.
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.
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.
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.
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.
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.
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).
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.