I’ve found lots of examples in C of programs illustrating buffer Overflows, including those of pointer rewrites which has been of great help in understanding how a buffer overflow works and memory safety etc. but I’ve yet to be able to find an example illustrating how such a buffer overflow can rewrite a pointer in such a way that it actually results in code execution?
Is this just not a thing, or is my google-fu rust y? Tried ChatGPT and my local Mistral and they both seem unable to spit out precisely what I’m asking, so maybe I’m wording this question wrong.
If anyone in here knows, could point me in the right direction? Thanks y’all btw love this community 🧡
So, I’m not going to discourage people from doing stuff that they’re interested in, but if you’re interested in heading down doing low-level security stuff like this as a career path, I’ll leave you with this piece of advice, which I think is probably more-valuable than the actual technical information I provided here:
A very great amount of security knowledge, and especially low-level security knowledge, has a short shelf life. That is, you spend time to understand something, and it’s only useful for a limited period of time.
In software engineering, if you spend time to learn an algorithm, it will probably be useful pretty much forever; math doesn’t change. Sometimes the specific problems that an algorithm is especially useful for go away, and sometimes algorithms are superseded by generally-superior algorithms, but algorithms have a very long shelf life.
Knowledge of software engineering at, say, a programming language level don’t last as long. There’s only so much demand for COBOL programmers today, though you can use things learned in one environment in another, to a fair degree. But as long as you choose a programming language that is going to be around for a long time, the knowledge you spend time acquiring can continue to be valuable for decades, probably your entire career.
Knowledge of a particular program has a shorter life. There are a very few programs that will be around for an extremely long period of time, like emacs, but it’s hard to know in advance which these will be (though my experience has been that open-source software tends to do better here). For example, I have gone through various version control systems – CVS, VCS, SVN, Bitkeeper, mercurial, git, and a handful of others. The time I spent learning the specifics of most of those is no longer very useful.
Your professional value depends on your skillset, what you bring to the table. If you spend a lot of time learning a skill that will be applicable for your entire working life, then it will continue to add to the value that you bring to the table for your entire working life. If you spend a lot of time learning a skill that will not be of great use in five or ten years, then the time you invested won’t be providing a return to you after that point.
That does not mean that everything in the computer security world has a short shelf life. Things like how public/private key systems work or understanding what a man-in-the-middle attack is remain applicable for the long haul.
But a lot of security knowledge involves understanding flaws in very specific systems, and those flaws will go away or become less relevant over time, and often dealing with low-level security, implementation characteristics of specific systems is an example of such a thing.
The world does need low-level computer security experts.
But I would suggest to anyone who is interested in a career in computer security to, when studying things, to keep in mind the likely longevity of what they are teaching themselves and ask themselves whether they believe that that knowledge will likely be relevant at the time that they expect to retire. Everyone needs to learn some short-shelf-life material. But if one specializes in only short-shelf-life things, then they will need to be committing time to re-learn new short-shelf-life material down the line as their current knowledge loses value. I’d try to keep a mix, where a substantial portion of what I’m learning will have a long shelf life, and the short-shelf-life stuff I learn is learned with the understanding that I’m going to need to replace it at some point.
I’ve spent time hand-assembling 680x0 and x86 code, have written exploits dependent upon quirks in particular compilers and for long-dead binary environments. A lot of that isn’t terribly useful knowledge in 2024. That’s okay – I’ve got other things I know that are useful. But if you go down this road, I would be careful to also allocate time to things that you can say with a higher degree of confidence will be relevant twenty, thirty, and forty years down the line.
Words of wisdom right here.
Personally, what bothers me about the security field is how quickly it becomes a counterproductive thing. Either by forcing people to keep working on time consuming processes like certifications or mitigation work (e.g. see the state of CVEs in the linux kernel) or simply by pumping out more and more engineers that have never put together a working solution in their lives. Building anything of value is already hard as it is nowadays.
Yeah I fully agree with the former in particular. The GRC side of things is just not that interesting and not that valuable. I do vulnerability management as a job which is somewhat depressing after a cybersec MSc, but honestly a job is a job and I don’t really believe it produces that much value to anyone, but neither does the entire company I work for, the entire system we live under incentivizes waste, and who am I to argue as long as I get paid?
When it comes to low level stuff, this is purely curiousity and self-fulfillment of understanding for me.