-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
*** invalid %N$ use detected *** #3944
Comments
Still fails for me |
Cant reproduce even with asan. Can u provide more info? Like a backtrace or another reproducer
|
ping
|
Okay, reproducible only on a PaX-enabled systems |
uh... why is %n ever being used? On Mon, Jan 11, 2016 at 5:00 PM, Anton Kochkov [email protected]
Jeff Crowell |
oh nope. not even there.. so its not used at all, maybe its a format string vuln with a specially crafted string. can you show a backtrace? |
no backtrace is available at that system with this error. |
Then drop pax :p
|
I get this same issue when trying to analyze an 8051 firmware. OS is Arch Linux, kernel 4.4.5-1-ARCH x86_64. Here's the version of radare I'm using (from the Arch Community repo):
And the command I'm running:
And finally the backtrace:
|
Please update to git and try again
|
The issue still exists on master. Non-stripped backtrace:
|
And here's the backtrace with local variables:
|
Apparently, Arch Linux's gcc adds The proper fix is to make diff --git a/global.mk b/global.mk
index 364a61a..a7c48ff 100644
--- a/global.mk
+++ b/global.mk
@@ -34,13 +34,13 @@ WWWROOT=${DATADIR}/radare2/${VERSION}/www
ifneq ($(SILENT),)
@echo LD $<
endif
- $(CC) $(LDFLAGS) -c $(CFLAGS) -o $@ $<
+ $(CC) $(LDFLAGS) -c $(CFLAGS) -U_FORTIFY_SOURCE -o $@ $<
.c.o:
ifneq ($(SILENT),)
@echo "CC $(shell basename $<)"
endif
- $(CC) -c $(CFLAGS) -o $@ $<
+ $(CC) -c $(CFLAGS) -U_FORTIFY_SOURCE -o $@ $<
-include $(TOP)/config-user.mk
-include $(TOP)/mk/platform.mk |
I don't like the idea of having to disable fortify, but i understand that changing that code is not easy and it will result in a big refactoring because the %$ syntax is hard to be replaced. I dont know which standard itconforms and i wonder if that works on bionic or windows too.. |
Wikipedia says that %$ is a POSIX thing and not in any version of the C standard. It seems to work fine with fortify disabled so it should work on other operating systems, but of course that increases the risk of input causing buffer overflows. |
Can you confirm this is still happening in master? |
@radare well, I have an idea - you won't believe this, but what about using radare2 own *printf implementations - for the standard formats it will fallback to the in-system printf, but it will add support for some very useful extensions. |
the thing is that i cant find any %N$ in the 8051 code. there’s a %N in the arm disassebler. but it can be fixed. not sure when this was having %N or %$
|
@radare still reproduceable on the PaX-enabled Hardened Gentoo. |
can you point to the file:line?
|
Not on this computer - may be will be lucky with the home one. This one has PTRACE disabled. |
@radare The issue is still happening for me, which isn't surprising since the file the problem statements are in ( You can find the problem lines with this command: grep -rn '%[0-9]\$' Which produces this output:
|
Does itbuilds if u disable that plugin? Can we check if fortity is set from cpp? Maybe we can just avoid building this code in this case
|
ping |
well the issue is there, but the code is not easily refactorizable to get rid of that %N$ thing :(
|
Not prioritae, moving to the next milestone. |
I recently removed all uses of %N$ from the 8051 analyzer. grep suggested by @cyrozap comes up empty. Can someone verify that this issue is resolved? |
let's close this for now |
Running on git master:
It doesn't crash now, but I do get the following errors:
The 8051 is an 8-bit CPU, not a 64-bit one, so I'm not sure where that "bits 64" is coming from or if that's now interfering with anything. Regardless, it seems to work now, so I think we can keep this issue closed. |
Thanks for fixing this, @astuder! |
@cyrozap the 64 bit error is because r2 tries to initialize to its defaults (asm.cpu=x86 asm.bits=64) a few times during startup. Not sure how to fix that, but I didn't see any negative impact in practice either so far. |
./run_r2.sh
from https://github.com/XVilka/hacklu/tree/master/demos/Firmware/demo5_it8502e[0x000000]> . ite_it8502.r2
pd 5
It quits with
*** invalid %N$ use detected ***
errorThe text was updated successfully, but these errors were encountered: