Hacking News

boomzilla

@Parody said in Hacking News:

@LaoC @boomzilla Looks flawed in both Chromish and Firefoxian browsers here (Windows 11) at 100% system scaling and 100% browser zoom. Looks improved after zooming to ~120%. Presumably the same would be true for system scaling, but I don't feel like messing with that right now.

Same here with Firefox and Edge on W11.
Removing the font-weight property in dev tools also makes the letters appear correctly

Ah, yes. On Chrome on Linux, too.

vs

(Links have their own font-weight styling.)

Gern_Blaanston

@Bulb said in Hacking News:

@BernieTheBernie From the timeline:

… so the software apparently is maintained, but they clearly don't care about bugs that cause crashes and possibly security issues.

Who said somewhere around here that their company no longer allows having notepad++ installed? Might actually be a founded decision after all.

It appears they finally fixed the problems on Sept. 8

Notepad++ v8.5.7 release: Vulnerability fixes | Notepad++

LaoC

@Arantor said in Hacking News:

@LaoC said in Hacking News:

The site don't seem to use any custom fonts

It's using Helvetica Neue, which depending on where they sourced it from and what combination of things you block may or may not render correctly.

OIC, I just didn't find it in the CSS before.

BernieTheBernie

@BernieTheBernie said in Hacking News:

Äpple OSes have to pätched ürgentzly because a manipuated image could lead to unwanted code execution; also the wallet app could be manipulated with a bad attachment:

Apple security releases

Anbd now cometh the next pätch for further security issues
(article from Heise.de in German):

heise online / Sep 21, 2023 / IT

Neuer Exploit: Apple aktualisiert wichtigste Betriebssysteme – auch iOS 17

Apple hat am Donnerstagabend erneut auf aktive Angriffe auf seine Betriebssysteme reagiert. Betroffen sind auch jüngste Versionen.

Congrats, dear Apple, you have become such popular that more and more hackerz are busy finding security issues in your products.
When will you have reached the popularity of Windows?
Anyways, the penguin will continue to stay far behind.

Bulb

@BernieTheBernie said in Hacking News:

Anyways, the penguin will continue to stay far behind.

Android uses Linux kernel, and it's more popular than iOS…

LaoC

@BernieTheBernie said in Hacking News:

Congrats, dear Apple, you have become such popular that more and more hackerz are busy finding security issues in your products.
When will you have reached the popularity of Windows?
Anyways, the penguin will continue to stay far behind.

That penguin that runs pretty much the entire infrastructure, 70% of handhelds worldwide and over half of all new consumer devices?

BernieTheBernie

@Bulb @LaoC I thought of the penguin on the desktop...
The penguin on phones is

LaoC

@BernieTheBernie said in Hacking News:

@Bulb @LaoC I thought of the penguin on the desktop...
The penguin on phones is

The only ways in which this distinction between desktop and handheld still makes sense is for web designers and as an excuse for MS for why their OS is as malware-ridden as it is—because pOpUlArItY! Lots of people (I bet it's the majority at least outside the US) do their banking and mailing primarily on their phones so there's absolutely no reason malware authors wouldn't consider them valuable targets, and the value of infiltrating internet infrastructure is obvious anyway.

loopback0

@BernieTheBernie said in Hacking News:

Congrats, dear Apple, you have become such popular that more and more hackerz are busy finding security issues in your products.

It's nothing new

Apple security releases

Bulb

@LaoC said in Hacking News:

distinction between desktop and handheld

Actually handheld, being newer, was developed with the benefit of hindsight that app isolation is needed, so all applications are isolated and subject to permission system. Desktop Linux has been introducing it with flatpak and snap(craft) and Windows introduced it for store apps, but most processes still run with access everywhere, so breaking in desktop is more likely to lead to ability to steal something useful.

Note that Windows store started with mandatory sandboxing, but they had to relax that requirement and eventually allowed old apps that run unsandboxed in it. This is in large part because only applications written using the newer “universal windows platform” API can run in the sandbox. The sandbox in snap(craft) requires much less use of special APIs, so it's much easier to ship Linux apps sandboxed.

jinpa

@Bulb said in Hacking News:

Who said somewhere around here that their company no longer allows having notepad++ installed? Might actually be a founded decision after all.

That was me. It was a governmental department rather than my employer per se.

Gustav

@BernieTheBernie said in Hacking News:

Notepad++ is popular among some people. Now enjoy beautiful security issues. You just need a document where a conversion of encodings is required, and a little bad code...

jarlob / Aug 21, 2023

GHSL-2023-112, GHSL-2023-102, GHSL-2023-103, GHSL-2023-092: Buffer Overflows in Notepad++ - CVE-2023-40031, CVE-2023-40036, CVE-2023-40164, CVE-2023-40166

Multiple memory safety violations in Notepad++ opening a crafted file.

I know I'm late to the party but I want to point out none of the 4 issues described has any actual security implications. Three are basic read-past-the-end bugs that at worst will crash the app. The one marked as "ARBITRARY CODE EXECUTION!!!!!!" doesn't have an exploit example attached that actually executes any arbitrary code, they just assume that it will result in ACE because every write past the end automatically means ACE, right? Right???

dkf

@Gustav Once you have an exploit to write off the end of the buffer, it becomes very hard to prove that an ACE is not possible. The rules have been broken; we're into wild code space...

Gustav

@dkf said in Hacking News:

@Gustav Once you have an exploit to write off the end of the buffer, it becomes very hard to prove that an ACE is not possible.

This is a very different statement from "ACE is possible".

Note that this is a heap buffer overflow. 99.99999999% of known ACE exploits use stack buffer overflows (can you guess why?). The number has been even higher since ASLR became mainstream.

LaoC

@Gustav said in Hacking News:

@dkf said in Hacking News:

@Gustav Once you have an exploit to write off the end of the buffer, it becomes very hard to prove that an ACE is not possible.

This is a very different statement from "ACE is possible".

"This issue may lead to an arbitrary code execution." is what the wording is. It's quite standardized for security advisories, they use "may" or "could" if it's thought possible but unconfirmed and something in the indicative for known exploits.

Note that this is a heap buffer overflow. 99.99999999% of known ACE exploits use stack buffer overflows (can you guess why?). The number has been even higher since ASLR became mainstream.

No. I can easily find half a dozen heap-based overflows with confirmed ACE just from this year, even without counting consecutive CVE numbers for multiple vulnerabilities in the same product or suite.
My subjective impression of developments is quite the opposite, and a crude search (search for "stack" or "heap" and limit to those CVEs with a link to "Known Exploited Vulnerabilities") seems to confirm it: stack-based vulnerabilities are going down (probably due to things like stack canaries that you can easily use in production code) while heap-based ones are getting more frequent; they're harder to exploit but also harder to defend against.

Gustav

@LaoC but have you SEEN those exploits? Can you CONFIRM they're actually ACE and not just DOS or something? Even one example is okay. I did the search you recommended and they're all very secretive about what the exploit actually did.

LaoC

@Gustav said in Hacking News:

@LaoC but have you SEEN those exploits? Can you CONFIRM they're actually ACE and not just DOS or something? Even one example is okay. I did the search you recommended and they're all very secretive about what the exploit actually did.

That's just the same as for the stack-based ones. Since Responsible Disclosure became a thing, people are either sending their exploit to the maintainers only or selling it to the spooks. The times of shouting "Hey, look at the 1337 new 0day I found!!!!1" for intertube cred are over. So, no, I haven't.

However, I have no reason to believe this is all made up and Tavis Ormandy is lying and Adobe would say "hey, our product contains a heap buffer overflow and people are actively using it to hack our customers, look how hard we suck!" if they weren't very sure that's actually the case.

dkf

@LaoC I'm of the opinion that any buffer overflow is bad news, even just for a read. But that doesn't mean it is something to have a panic over; just ensure that you know what the bounds on the buffer are and check them. The compiler will remove the check if it can prove that it is safe to do so (in a release build), and if the check is still there then there is a code path that probably needs it.

Gustav

@LaoC said in Hacking News:

@Gustav said in Hacking News:

@LaoC but have you SEEN those exploits? Can you CONFIRM they're actually ACE and not just DOS or something? Even one example is okay. I did the search you recommended and they're all very secretive about what the exploit actually did.

That's just the same as for the stack-based ones.

It cannot be the same as the stack-based ones because you won't overwrite any return addresses by simply going higher and higher - which is what virtually every overflow ACE exploit relies on.

There are open source exploits for Heartbleed, for Shellshock, for that Log4j thing, and many more. Not all exploits are embargoed. There must be the source code for a heap buffer overflow ACE exploit if such thing is possible at all. So until I see one - or someone explains the exact method it could be achieved - I'm going to assume it's not in fact possible and all the "may lead to ACE" you see in CVE descriptions are just the usual security researchers' fearmongering who abuse the fact you can't prove ACE isn't possible.

LaoC

This post is deleted!

LaoC

@Gustav said in Hacking News:

@LaoC said in Hacking News:

@Gustav said in Hacking News:

@LaoC but have you SEEN those exploits? Can you CONFIRM they're actually ACE and not just DOS or something? Even one example is okay. I did the search you recommended and they're all very secretive about what the exploit actually did.

That's just the same as for the stack-based ones.

It cannot be the same as the stack-based ones because you won't overwrite any return addresses by simply going higher and higher - which is what virtually every overflow ACE exploit relies on.

The secrecy is what is the same.

There are open source exploits for Heartbleed, for Shellshock, for that Log4j thing, and many more. Not all exploits are embargoed.

Am I getting this right that you're trying to prove your thesis that "99.99999999% of known ACE exploits use stack buffer overflows" by naming three exploits, none of which relies on stack buffer overflows?

There must be the source code for a heap buffer overflow ACE exploit if such thing is possible at all. So until I see one - or someone explains the exact method it could be achieved - I'm going to assume it's not in fact possible and all the "may lead to ACE" you see in CVE descriptions are just the usual security researchers' fearmongering who abuse the fact you can't prove ACE isn't possible.

OK, if you say so.

topspin

It was possible two decades ago, and exploits only get better.

.:: Phrack Magazine ::.

Gustav

@LaoC said in Hacking News:

Am I getting this right that you're trying to prove your thesis that "99.99999999% of known ACE exploits use stack buffer overflows" by naming three exploits, none of which relies on stack buffer overflows?

No, you're not getting this right. You're pulling the equivalent of "I can't tell you where I worked the last 5 years because I'm under NDA". For all I know, you could very well be unemployed.

If a TYPE OF exploit exists, then an EXAMPLE OF it very likely exists somewhere on Github. Therefore, it's not unreasonable to ask for one.

There's as much evidence for an ACE vulnerability in Notepad++ as there is for existence of God ("you can't prove He doesn't"). So I'm going to believe there's an ACE vulnerability in Notepad++ as much as I believe in God.

LaoC

@Gustav said in Hacking News:

@LaoC said in Hacking News:

Am I getting this right that you're trying to prove your thesis that "99.99999999% of known ACE exploits use stack buffer overflows" by naming three exploits, none of which relies on stack buffer overflows?

No, you're not getting this right.

What part of it, the thesis or the exploits you named?

You're pulling the equivalent of "I can't tell you where I worked the last 5 years because I'm under NDA". For all I know, you could very well be unemployed.

No, I'm pulling a
I'm telling you I find the evidence I have credible enough. If you want to believe Adobe is actively trying to make their software look worse than it is by inventing exploits that don't exist, that's fine. Not my job to convince you.

If a TYPE OF exploit exists, then an EXAMPLE OF it very likely exists somewhere on Github. Therefore, it's not unreasonable to ask for one.

Go look.
Edit: @topspin spared you the work.

Gustav

@topspin said in Hacking News:

It was possible two decades ago, and exploits only get better.

.:: Phrack Magazine ::.

Correct me if I wrong, but isn't it about vulnerability in malloc that's exploited by specifically crafted binary, rather than a buffer overflow attack exploiting a pre-existing binary?

topspin

@Gustav not really. Section 3.6.1.2 gives this as a vulnerable program:

$ set -o noclobber && cat > vulnerable.c << EOF
#include <stdlib.h>
#include <string.h>

int main( int argc, char * argv[] )
{
        char * first, * second;

/*[1]*/ first = malloc( 666 );
/*[2]*/ second = malloc( 12 );
/*[3]*/ strcpy( first, argv[1] );
/*[4]*/ free( first );
/*[5]*/ free( second );
/*[6]*/ return( 0 );
}
EOF

Couldn’t get much more generic for a heap overflow.

dkf

@Gustav The point is that there have been wild crafted attacks with that small a crack in the application's correctness. Yes, they are difficult to do by comparison with some of the other types of attack (such as XSS or SQL Injection) but they do exist.

What really gets me worked up is where some Rust advocate claims that buffer overruns are the only significant type of software vulnerability and that Rust is therefore the One True Solution for all software correctness. It shows a literally spectacular level of ignorance of the space of potential software faults.

LaoC

@Gustav said in Hacking News:

@topspin said in Hacking News:

It was possible two decades ago, and exploits only get better.

.:: Phrack Magazine ::.

Correct me if I wrong, but isn't it about vulnerability in malloc that's exploited by specifically crafted binary, rather than a buffer overflow attack exploiting a pre-existing binary?

malloc is a C library function. Why would you craft a binary to "exploit" code that's included with that very binary?

It's stated in the second sentence of TFA:

The first one explains in detail the GNU C Library implementation of the malloc interface and how it can be abused to exploit buffer overflows in malloc space

dkf

@topspin Copying an attacker-specified string of entirely unknown length into a fixed size buffer can cause a problem?! Oh no! If only there was an easy way to avoid this by calling strlen() first to find the size of the buffer to make, but there isn't any such way to do that...

topspin

@dkf the entire discussion is about the point that this is exploitable even on the heap, not on the stack.

PleegWat

@dkf said in Hacking News:

@topspin Copying an attacker-specified string of entirely unknown length into a fixed size buffer can cause a problem?! Oh no! If only there was an easy way to avoid this by calling strlen() first to find the size of the buffer to make, but there isn't any such way to do that...

The problem is there are a lot of wrong ways to do that copy in the standard library, and not a lot of correct ones. And snprintf(dst, dstsz, "%s", src) is one of the wrong ones, at least in the general case, because truncating arbitrary strings is also a bug.

cvi

@PleegWat

auto const needed = snprintf(dst, dstsz, "%s", src);
if( needed > dstsz ) throw error::YourMotherWasAHamster{};

kazitor

@LaoC said in Hacking News:

Adobe is actively trying to make their software look worse

They call it ‘releasing an update’

Gustav

@LaoC said in Hacking News:

@Gustav said in Hacking News:

@topspin said in Hacking News:

It was possible two decades ago, and exploits only get better.

.:: Phrack Magazine ::.

Correct me if I wrong, but isn't it about vulnerability in malloc that's exploited by specifically crafted binary, rather than a buffer overflow attack exploiting a pre-existing binary?

malloc is a C library function. Why would you craft a binary to "exploit" code that's included with that very binary?

Dunno. Privilege escalation? I didn't read the article carefully, I was in rush.

It's stated in the second sentence of TFA:

The first one explains in detail the GNU C Library implementation of the malloc interface and how it can be abused to exploit buffer overflows in malloc space

Okay, thanks. So it is in fact possible, assuming both W^X and ASLR are disabled (as was the case at the time of the article, but virtually never nowadays, at least on desktop and general purpose server platforms).

LaoC

@kazitor said in Hacking News:

@LaoC said in Hacking News:

Adobe is actively trying to make their software look worse

They call it ‘releasing an update’

QOOC thread is

LaoC

@Gustav said in Hacking News:

@LaoC said in Hacking News:

@Gustav said in Hacking News:

@topspin said in Hacking News:

It was possible two decades ago, and exploits only get better.

.:: Phrack Magazine ::.

Correct me if I wrong, but isn't it about vulnerability in malloc that's exploited by specifically crafted binary, rather than a buffer overflow attack exploiting a pre-existing binary?

malloc is a C library function. Why would you craft a binary to "exploit" code that's included with that very binary?

Dunno. Privilege escalation? I didn't read the article carefully, I was in rush.

This is not how this works. This is not how any of this works.
You may want to make a binary that exploits a kernel bug for local privilege escalation, but exploiting malloc doesn't gain you anything locally. It's like breaking a window from the inside in order to burglarize your own house.

It's stated in the second sentence of TFA:

The first one explains in detail the GNU C Library implementation of the malloc interface and how it can be abused to exploit buffer overflows in malloc space

Okay, thanks. So it is in fact possible, assuming both W^X and ASLR are disabled (as was the case at the time of the article, but virtually never nowadays, at least on desktop and general purpose server platforms).

O
For one thing, ASLR is not a system-global setting that you can just enable and you're fine. If the program author forgot to enable PIE (edit: or was unable to because Rust ), there's nothing the OS can do, and it happens even to fairly competent people.

But even if it's on, it makes things harder but not impossible:

Advanced Exploit Development - Return-Oriented Programming (ROP) | UncleSp1d3r Blog

Jun 16, 2010

Exploit writing tutorial part 10 : Chaining DEP with ROP – the Rubik’s[TM] Cube | Corelan Cybersecurity Research

About 3 months after finishing my previous exploit writing related tutorial, I finally found some time and fresh energy to start writing a new article. In the previous tutorials, I have explained the basics of stack based overflows and how they can lead to arbitrary code execution. I discussed...

(no, none of them has actual exploits for actual software)

topspin

@Gustav said in Hacking News:

It's stated in the second sentence of TFA:

The first one explains in detail the GNU C Library implementation of the malloc interface and how it can be abused to exploit buffer overflows in malloc space

Okay, thanks. So it is in fact possible, assuming both W^X

From how I skimmed the article, W^X doesn't help here, as you can write a chosen value anywhere in the address space. That doesn't have to be in the code segment.

and ASLR are disabled (as was the case at the time of the article, but virtually never nowadays, at least on desktop and general purpose server platforms).

Of course, since it's from a time when "heap overflows can be exploited" was news. It's old news, which is why you complained that new bug reports assume that as generally accepted and don't come with an elaborate technical demonstration. Importantly, when they say "this is being actively exploited in the wild", there is no reason to doubt that just because the exploit isn't linked. You'd probably have to look at exploit sites instead.
In the meantime, new mitigation techniques have been implemented, and new ways to circumvent them, so the arms race continues. ASLR doesn't stop exploits, it just requires more complex schemes.

Some random further resources (which I'm not going to read myself ):

https://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirov-dowd.pdf

SAPCAR Heap Buffer Overflow: From crash to exploit

GitHub - shellphish/how2heap: A repository for learning various heap exploitation techniques.

A repository for learning various heap exploitation techniques. - shellphish/how2heap

LaoC

@topspin said in Hacking News:

@Gustav said in Hacking News:

It's stated in the second sentence of TFA:

The first one explains in detail the GNU C Library implementation of the malloc interface and how it can be abused to exploit buffer overflows in malloc space

Okay, thanks. So it is in fact possible, assuming both W^X

From how I skimmed the article, W^X doesn't help here, as you can write a chosen value anywhere in the address space. That doesn't have to be in the code segment.

It does help a bit because you can't write code anywhere and simply jump to it if segments are never both executable and writable. But that's what ROP circumvents by expressing your exploit in terms of existing code snippets from the application that are necessarily in executable segments already.

dkf

@LaoC And there are whole other classes of exploit that don't need this sort of thing. The classic is SQL Injection, where the problem isn't writing off the end of the string buffer, but instead putting unexpected things in that string.

LaoC

@dkf Sure, they're just unlikely to be relevant for the question whether Notepad++ is exploitable.

LaoC

Nguyễn Tiến Giang (Jang) / Sep 25, 2023 / blog

[P2O Vancouver 2023] SharePoint Pre-Auth RCE chain (CVE-2023–29357 & CVE-2023–24955)

Brief I may have achieved successful exploitation of a SharePoint target during Pwn2Own Vancouver 2023. While the live demonstration lasted only approximately 30 seconds, it is noteworthy that the process of discovering and crafting the exploit chain consumed nearly a year of meticulous effort and...

JWT FTW!
As JWT was a topic here just these days: the only JWT library I know implements the none algorithm but you have to go out of your way to enable it and it still warns you. As it should be. Does any widely used component do it differently or is it only MS bring the moron kings again here?

Medinoc

@Gustav said in Hacking News:

@LaoC said in Hacking News:

It cannot be the same as the stack-based ones because you won't overwrite any return addresses by simply going higher and higher - which is what virtually every overflow ACE exploit relies on.

There are open source exploits for Heartbleed, for Shellshock, for that Log4j thing, and many more. Not all exploits are embargoed. There must be the source code for a heap buffer overflow ACE exploit if such thing is possible at all. So until I see one - or someone explains the exact method it could be achieved - I'm going to assume it's not in fact possible and all the "may lead to ACE" you see in CVE descriptions are just the usual security researchers' fearmongering who abuse the fact you can't prove ACE isn't possible.

You cannot* overwrite a return address with a heap buffer overflow, but you could overwrite the vtable pointer or a nearby C++ (or some other OOP language) object that happens to have a vtable.

_{*I'm sure in some planetary-alignment-grade circumstances you could possibly have a heap buffer overflow that goes all the way up to the stack without encountering a non-writable page first...}

Speaking of heap buffer overflows, apparently there's one in libwebp that was recently patched out in most browsers. -- this time with a confirmed ACE exploit in at least one program that used libwebp.
https://www.bleepingcomputer.com/news/security/google-assigns-new-maximum-rated-cve-to-libwebp-bug-exploited-in-attacks/

cvi

Dan Goodin / Sep 26, 2023 / Security

GPUs from all major suppliers are vulnerable to new pixel-stealing attack

A previously unknown compression side channel in GPUs can expose images thought to be private.

Doesn't seem that practical at the moment (takes hours), but a fun new way that exploits transparent on-device compression.

Atazhaia

@cvi

For GPU.zip to work, a malicious page must be loaded into the Chrome or Edge browsers. Under-the-hood differences in the way Firefox and Safari work prevent the attack from succeeding when those browsers process an attack page. Another requirement is that the page linked to in the iframe must not be configured to deny being embedded by cross-origin websites.

smug Firefox noises

topspin

@cvi said in Hacking News:

Doesn't seem that practical at the moment (takes hours)

Wasting a few hours on the victim's computer isn't much of a concern for the attacker.

Atazhaia

@topspin said in Hacking News:

@cvi said in Hacking News:

Doesn't seem that practical at the moment (takes hours)

Wasting a few hours on the victim's computer isn't much of a concern for the attacker.

I waste enough time on my own computer as it is, I don't need someone else to do it too.

dkf

@topspin said in Hacking News:

@cvi said in Hacking News:

Doesn't seem that practical at the moment (takes hours)

Wasting a few hours on the victim's computer isn't much of a concern for the attacker.

But the chance if having exactly the same thing (and having that be something you want to know about) at that place in the screen buffer for all that time isn't great.

Gustav

@Atazhaia said in Hacking News:

@cvi

For GPU.zip to work, a malicious page must be loaded into the Chrome or Edge browsers. Under-the-hood differences in the way Firefox and Safari work prevent the attack from succeeding when those browsers process an attack page. Another requirement is that the page linked to in the iframe must not be configured to deny being embedded by cross-origin websites.

smug Firefox noises

I wonder if it has something to do with their renderer being written in Rust.

Arantor

@Gustav Safari isn’t written in Rust last I checked.

Gustav

@Arantor I wonder if it has something to do with their renderer managing to avoid a type of bug that's very common in C++ code but wouldn't be possible in Rust, while Chrome fell into it head first.