Date: Mon, 13 Nov 2017 15:38:40 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 223653] Extremely serious string manipulation problem in -HEAD Message-ID: <bug-223653-7@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223653 Bug ID: 223653 Summary: Extremely serious string manipulation problem in -HEAD Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: karl@denninger.net Take the following tiny code snippet: #include <stdio.h> #include <string.h> int main(argc, argv) int argc; char *argv[]; { char tmp[132]; char tmp2[132]; strcpy(tmp, "00 01 02 03 04 05 06"); printf("First: [%s]\n", tmp); strcpy(tmp, &tmp[3]); printf("Second: [%s]\n", tmp); strcpy(tmp, &tmp[3]); printf("Third: [%s]\n", tmp); strcpy(tmp, &tmp[3]); printf("Fourth: [%s]\n", tmp); strcpy(tmp, "00 01 02 03 04 05 06"); printf("2-First: [%s]\n", tmp); strcpy(tmp2, &tmp[3]); strcpy(tmp, tmp2); printf("2-Second: [%s]\n", tmp); strcpy(tmp2, &tmp[3]); strcpy(tmp, tmp2); printf("2-Third: [%s]\n", tmp); strcpy(tmp2, &tmp[3]); strcpy(tmp, tmp2); printf("2-Fourth: [%s]\n", tmp); } Compile it on FreeBSD 12.0-CURRENT #0 r325754: Mon Nov 13 08:02:13 CST 2017= on an RPI3 and run it. root@rpi3:/data/HD-MCP # ./test2 First: [00 01 02 03 04 05 06] Second: [02 04 05 05 06 06] Third: [04 05 05 06 06] Fourth: [05 05 06 06] 2-First: [00 01 02 03 04 05 06] 2-Second: [01 02 03 04 05 06] 2-Third: [02 03 04 05 06] 2-Fourth: [03 04 05 06] root@rpi3:/data/HD-MCP # Yes, I'm aware that strcpy with overlapping strings is not safe in all instances (strcpy is of course unsafe if the source can be longer than where you are copying into) but historically it has been safe when used to remove some number of bytes from the left side ("front") of a string as the destination cannot overflow and on a byte-wise copy code that is generated = it stops as expected after the trailing null is copied over. There's also no note in the current man page that this is unsafe. Rewriting the strcpys to use memmove corrects the above problem (memmove specifically= is ok to use in all cases of overlapping storage of course) but this change is likely to bite a material number of people and has not been a problem on any architecture I've seen under FreeBSD until fairly recently (it did not cause problems with a February build of -HEAD on the RPI3/arm64, for example.) I note that if I try to link OPENSSL into a piece of code I have here I get= a trap immediately on an "illegal opcode" when I try to execute the resulting binary, which may be due to this happening somewhere in the initialization code. I get no frame labels on the backtrace, and the trap occurs before main() starts executing (a breakpoint set on the first actual instruction in main() fails to be reached) so unfortunately I do not have a better trace on what's going on. I suspect the behavior above, or some other artifact of t= he same change, is responsible for the below; the code in question has been running on an RPI2 (which right now I am using under FreeBSD 11.0-STABLE #1 r313159M) and various Intel (i386 and Amd64) architectures, also under 11-Stable, for a long period of time: root@rpi3:/data/HD-MCP # lldb hd-mcp (lldb) target create "hd-mcp" Current executable set to 'hd-mcp' (aarch64). (lldb) run -n Process 924 launching Process 924 launched: '/data/HD-MCP/hd-mcp' (aarch64) Process 924 stopped * thread #1, name =3D 'hd-mcp', stop reason =3D signal SIGILL: illegal trap frame #0: 0x00000000403342e8 -> 0x403342e8: .long 0x0ee0e000 ; unknown opcode 0x403342ec: ret 0x403342f0: stp x28, x19, [sp, #-0x20]! 0x403342f4: stp x29, x30, [sp, #0x10] (lldb) bt * thread #1, name =3D 'hd-mcp', stop reason =3D signal SIGILL: illegal trap * frame #0: 0x00000000403342e8 frame #1: 0x0000000040082ad8 frame #2: 0x0000000040081ab4 (lldb) If I leave OpenSSL out (I have a "no security" version that #ifdef's it out) then the code compiles and runs fine. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-223653-7>