OS WARS MEGA THREAD (Now debating proprietary vs. open-source!)

Doesn't mixing control and data blocks actually make it more likely that heap corruption will be noisy, rather than silent? If you write over a data item with zeroes, it can screw up the state and output of your program without the runtime library or OS ever being aware of it. If you clobber a heap control block, it's fairly likely that the allocator will choke on inconsistent state the next time it walls through the free list, scream about memory corruption on stderr, and kill the program before any more calculations are done on bad data.

It's silent because it will choke not when the overflow happens but on next malloc() / free() which may be in a completely unrelated part of the program. Also there are scenarios that free() may never be called because the program finishes.

Also by carefully crafting your data you can trick the allocator to overwrite arbitrary memory locations... such as the return address causing the cpu to jump into the code you have loaded into the buffer.

http://www.mathyvanhoef.com/2013/02/understanding-heap-exploiting-heap.html
 
It's silent because it will choke not when the overflow happens

But that's going to happen with any write to a present, user-mode, read-write page, and isn't dependent on allocator implementation.

You'd need a specially designed CPU architecture to catch every buffer overflow as it happens, or else you'd need to be running interpreted code where every memory access is verified before it is made.

but on next malloc() / free() which may be in a completely unrelated part of the program. Also there are scenarios that free() may never be called because the program finishes.

Yes, but it will choke in these scenarios, whereas an allocator with separate control and data blocks won't, so it's still noisier, if not as noisy as we'd like it to be.


Also by carefully crafting your data you can trick the allocator to overwrite arbitrary memory locations... such as the return address causing the cpu to jump into the code you have loaded into the buffer.

OK, that is an actual problem with mixing control and data blocks. It could be mitigated by signing each control block with a random key, though I suppose it might impact performance quite a bit for programs that have a lot of allocator activity.
 
With regards to "forced" updates, I'm on 10 now. But only because, apparently, "schedule the upgrade for two Saturdays ahead at 1 AM" actually means "DO IT NOW!!!!!!". Several hours and one unplanned all-nighter later, and I haven't had the best introduction to it... No idea what I did wrong, I'm sure that I clicked on the postpone button (don't even remember there being a "upgrade now" button). I can't complain though, I deliberately opted into the upgrade several months back because I needed to for work. I guess she got fed up with my procrastinating... :lol:
 
You'd need a specially designed CPU architecture to catch every buffer overflow as it happens, or else you'd need to be running interpreted code where every memory access is verified before it is made.

Not true. See libefence (from 1987!) for a relatively trivial hack which does just that. Or valgrind -- but that's heavy artillery.

OK, that is an actual problem with mixing control and data blocks. It could be mitigated by signing each control block with a random key, though I suppose it might impact performance quite a bit for programs that have a lot of allocator activity.

First of all, the problem is mitigated by keeping control and data structures on separate pages. Yes, it really is that simple. FreeBSD's jemalloc does exactly that. Second, no, heavy crypto is not needed see: https://events.ccc.de/congress/2005/fahrplan/attachments/636-CCCmallocyy.pdf

Third, it blows my mind that we've known since 2000 or so that nearly all buffer overflow attacks can be stopped dead cold by a combination of stack-non-exec, heap-non-exec, canary-on-stack and ASLR patches, which are all relatively trivial -- and 15 years later you still don't see them included in mainline OSes.
 
Last edited:
Not true. See libefence (from 1987!) for a relatively trivial hack which does just that. Or valgrind -- but that's heavy artillery.

Well, yes, if you are in a debugging environment and can afford to burn 2 * page size for even the smallest allocations. In the more general case, you need either a special CPU architecture or interpreted code.
 
Well, yes, if you are in a debugging environment and can afford to burn 2 * page size for even the smallest allocations. In the more general case, you need either a special CPU architecture or interpreted code.

A simple canary check on each malloc/free would make it much safer without causing a heavy performance penalty.
 
Now Microsoft got really nasty - if you are not carefully ready the update to Windows 10 popup, you are clicking the wrong button and schedule a mandatory update to Windows 10 someday late at night. You have to pay attention to the small link "Don't plan" in the wall of text.

If Microsoft wonders WHY I am not updating to Windows 10 yet? Such behaviour is it. That is the kind of communication, malware does.
 
I turned the automatic updates off a long time ago. No need to worry about Microsoft Malware :P
No, now you just need to worry about malware that takes advantage of your unpatched system...
 
I turned the automatic updates off a long time ago. No need to worry about Microsoft Malware :P

Have I missed something or are you Win 7? I thought the point was you couldn't turn off updates in Win 10, you could only postpone, at best. 'tis why I'm still on Win 7 with auto off and can pick and choose - some unwanted updates were BSOD fodder
 
Now Microsoft got really nasty - if you are not carefully ready the update to Windows 10 popup, you are clicking the wrong button and schedule a mandatory update to Windows 10 someday late at night. You have to pay attention to the small link "Don't plan" in the wall of text.

If Microsoft wonders WHY I am not updating to Windows 10 yet? Such behaviour is it. That is the kind of communication, malware does.

This.
And also the fact that since XP, Windows is going downhill so fast that the words "adware", crapware" and "spyware" can now be used to accurately describe their latest effort.
 
No, now you just need to worry about malware that takes advantage of your unpatched system...

I've been running the current install of Windows 7 for 3 years now without any complications. 3rd party antiviruses do a good enough job protecting the system from the usual threats.

Getting attacked would be highly inconvenient, but the probability of it is low enough to where the certainty of Microsoft's constant annoyance is worth the risk.

---------- Post added at 13:19 ---------- Previous post was at 13:18 ----------

Have I missed something or are you Win 7?

Windows 7. Not going to update until I buy the next computer, which will be no sooner than GeForce 1000 series.
 
I've been running the current install of Windows 7 for 3 years now without any complications. 3rd party antiviruses do a good enough job protecting the system from the usual threats.

:facepalm:

You love risks, don't you?
 
:facepalm:

You love risks, don't you?

Not to :facepalm:your :facepalm: here, but I feel compelled to defend RF--and I don't spend a lot of time defending him OR Windows:lol:

But IMO his solution is perfectly reasonable. If something works for you, it works for you. Just one thing though--if one insists on using Windows, I STRONGLY recommend having MalwareBytes with it. It doesn't cover everything, but it is free and covers most things, and it made me pretty happy back in my Windows days:tiphat:
 
But IMO his solution is perfectly reasonable. If something works for you, it works for you. Just one thing though--if one insists on using Windows, I STRONGLY recommend having MalwareBytes with it. It doesn't cover everything, but it is free and covers most things, and it made me pretty happy back in my Windows days:tiphat:

The problem is that you need your updates for the various communication subsystems ASAP, so not using automatic updates is either stupid or a lot of effort. The RF solution works well for a computer that is physically not connected to any network. Even if you just have an internal network without internet gateway, you still have a few possible ways to get a really bad virus into your network, which you need to handle as well.

Remember: Any anti-virus software can only detect known threats or unknown threats based on a known recipe. Most zero-day exploits are invisible for them.
 
Why not all of them?
5jjOrma.png


Got a bit carried away when I found out that it is possible to start multiple vmWare Player instances. :)
 
Back
Top