Comments for root labs rdist

Comment on Keeping skills current in a changing world by Ross C

Ross C — Sat, 18 May 2013 22:28:08 +0000

I agree completely. I also think unrealistic assumptions about compensation contribute to the illusion of age discrimination — there are too many grey-haired engineers who think that they’re automatically entitled to ever-increasing salaries as they age. (I say this as a semi-grey-haired 41-year old). Software engineers do get better (and thus more valuable) as they get older, but the difference is not as great as it might be in other professions.

Comment on Keeping skills current in a changing world by Jordan

Jordan — Sat, 11 May 2013 03:39:36 +0000

Hear, hear.

I’m 33, on my way downhill from technical relevance as a security research (or so I’m told), and I even spend much of my daylight hours doing management these days.

But at night, I go home and work on fun things. Taking Boneh’s crypto course from coursera, playing CTF challenges. Learning hardware hacking by building some raspberry pi and arduino gadgets around the house. There’s a wealth of resources out there if you try. I don’t think age has as much to do with it as a new educational model where you are not spoon fed. You pick the topic, you pick the deadline.

Comment on Keeping skills current in a changing world by Lennie

Lennie — Mon, 06 May 2013 19:48:19 +0000

The other way is to get involved in an open source project. You want cloud ? Try OpenStack, lots of things one could do there. It’s Python, if you have never used Python it should be pretty easy to pick up. You just need a modern desktop machine that can run several VMs at the same time.

There are lots of companies looking for people to work on OpenStack solutions.

Comment on History of memory corruption vulnerabilities and exploits by Tim Newsham

Tim Newsham — Wed, 17 Apr 2013 01:41:23 +0000

A couple of (late) comments on the comments:
1) stack direction will not solve the problem. Often buffer overflows happen not in the function containing the buffer but in one of the called functions. There will be a return address somewhere in memory after the buffer no matter which direction the stack grows in.
2) Code signing does nothing to prevent arbitrary code execution post-exploitation. An attacker can dynamically generate and execute code as needed once control flow has been hijacked. Check out some of the small interpreters available in professional exploit kits such as Core Impact or Metasploit Framework, for example.
3) This blog would indeed be a great platform for telling the world about your company’s new contest and about male virility!

Comment on History of memory corruption vulnerabilities and exploits by Watson Bernard Ladd

Watson Bernard Ladd — Wed, 20 Mar 2013 13:45:18 +0000

Easy solution: Use memory-safe languages so that we don’t have exploits from bugs. This doesn’t solve all security problems, like Confused Deputies, but does solve most of them. Ada, Java, SML, etc. are all much safer then C, and in many cases just as fast.

Comment on History of memory corruption vulnerabilities and exploits by @secolive

@secolive — Mon, 04 Feb 2013 12:18:26 +0000

Stacks are an interesting, venerable piece of legacy. For example, having a stack grow downwards was vey useful at the time there was no virtual memory, but it also now makes overwriting return adresses much easier. Why the industry could not move to upwards stack is a bit of a puzzle to me. Also, we keep wanting to mix automatic variables (data pane) and return adresses (control pane) on the same stack. Shouldn’t be too difficult to use two stacks to stop mixing control and data panes here. Would mean a redefinition of the calling conventions, but this can easily be done when introducing new platforms.

Whatever exploitation technique is used, at some point the attacker wants to execute arbitrary code. A good mitigation is to only allow execution of signed code. iOS chose that road and almost succeeded. The failure? The OS is allowed to turn that mechanism off, for whatever reason. This is a perfect illustration of the too-big TCB. Actually, a way to see it is that you need different levels of trusts, and the most-trusted component should be a mechanism whose sole purpose is to make sure only signed code is allowed execution as a given privilege, also managing trust chains.

In conclusion, with all defenses we have now (NX, ASLR…) we are really hacking around the issues instead of fixing the core problems in the architecture. Granted, easier said than done :)

@secolive