[HN Gopher] Smashing the Stack for Fun and Profit (1996)
___________________________________________________________________
Smashing the Stack for Fun and Profit (1996)
Author : keskadale
Score : 129 points
Date : 2021-01-24 05:35 UTC (1 days ago)
(HTM) web link (phrack.org)
(TXT) w3m dump (phrack.org)
| hushhush wrote:
| This paper also inspired the recent academic paper "Attacking
| Zcash Protocol For Fun And Profit" available at
| https://attackingzcash.com and on IACR:
| https://eprint.iacr.org/2020/627
|
| It describes new kinds of metadata leakage attacks that can be
| launched against privacy coins, by adversaries with large
| budgets, such as professional criminal organizations, blockchain
| analysis companies and nation states. The privacy coin HUSH has
| developed this defensive technology and was first to implement it
| in September 2019.
|
| There is a YouTube video where the author explains why he named
| the paper this way, this link has the timestamp where it's talked
| about: https://youtu.be/berM7Dnnoz4?t=405
|
| "This is a whole new research field I am creating, that is why I
| called it Attacking Zcash Protocol For Fun And Profit, just like
| Smashing The Stack for Fun And Profit, it created a whole new
| field"
|
| Also, for the hardcore HN nerds: The paper focuses on Zcash
| Protocol, but the ideas apply to any cryptocoin with a
| transaction graph, so Monero is definitely vulnerable. Much more
| vulnerable that Zcash Protocol.
| JoJoBinks wrote:
| Interesting. So hush is the only privacy coin in your opinion?
| no-dr-onboard wrote:
| This has been required reading for all the pentesters at my org
| for the past 20 years.
| notsureaboutpg wrote:
| This was required reading in my university's CS program.
| rixrax wrote:
| Should propably be required reading for every programmer and
| especially for those that work with memory unsafe languages.
| With a side of modern mitigation techniques.[0]
|
| [0] https://en.m.wikipedia.org/wiki/Buffer_overflow (See buffer
| overflow protection)
| e12e wrote:
| A simple compare and contrast between C and zig/rust/D might
| be interesting - or even golang for that matter (the idea
| being that code could be reasonably similar, and yet somewhat
| idiomatic - and illustrate how the C code is exploitable, but
| the safe language version isn't - except when _made_ to be).
| jdblair wrote:
| Reading this article back in the day is how I learned how stack
| smashing works! I also remember when the EFF stopped hosting
| Phrack because most of their bandwidth was people downloading
| every issue off the EFF's web server.
| [deleted]
| jdblair wrote:
| Correction: it was hosted on an anonymous FTP server, not a web
| server. Also, I was one of those people who downloaded every
| issue, probably with ncftp.
| hegzploit wrote:
| I sometimes wish time would rewind so I can experience the
| hacking scene in it's full glory.
| waynecochran wrote:
| The internet was open and fun back in the day. But evil people
| are why we can't have that anymore.
| alecco wrote:
| Gera's Insecure Programming tutorial on advanced Buffer Overflows
| was quite seminal. The site is gone but there's a GitHub repo
| now.
|
| https://github.com/gerasdf/InsecureProgramming
| NOGDP wrote:
| http://smashthestack.org/wargames.html
|
| > The Smash the Stack Wargaming Network hosts several Wargames. A
| Wargame in our context can be described as an ethical hacking
| environment that supports the simulation of real world software
| vulnerability theories or concepts and allows for the legal
| execution of exploitation techniques. Software can be an
| Operating System, network protocol, or any userland application.
| tekstar wrote:
| This article, and then working through the book "Hacking and the
| Art of Exploitation" taught me the true fundamentals of the C
| programming language, and Linux. The other key ingredient was
| working through the classic "digital evolution" wargames where
| you'd SSH into a box as level1 and work your way up from there.
| bluedino wrote:
| Another good book is 'Reversing: Secrets of Reverse
| Engineering'
|
| Books like that should be required reading when learning C. It
| shows you so much that the typical book won't cover.
| tekstar wrote:
| Yes! What it taught me was, to master a layer of abstraction,
| learn the layer it sits on top of as well.
| m00dy wrote:
| Same here. It also inspired me for my master thesis which is
| 'Using Bitcoin For Fun and Profit'.
| jcpham2 wrote:
| Slashdot circa 2011 "bitcoin mining for fun and profit"
|
| Phrack is standard required reading
| tylerjwilk00 wrote:
| Your comment caused a forgotten memory to pop up to the
| surface. Did you by chance happen to participate in the Zebulun
| Cyber Army Challenge(s) [1]?
|
| Those games were very rewarding for a high schooler on the
| early internet.
|
| [1] https://www.ca-zeb.com/
| zith wrote:
| Exactly the same experience as me. I got pretty deeply involved
| in the digital evolution community.
|
| Great way to spend my teenage years, and a great foundation to
| have while programming in any language. :)
| f00zz wrote:
| A classic, but these days if you want to reproduce those bugs you
| need to build your code with -fno-stack-protector, enable
| executable stack, disable ASLR in the kernel, etc.
| wizzwizz4 wrote:
| Not really. If you can overwrite the return address, and you
| have some time to plan out your payload in advance, you can
| write a program by "returning" into other bits of the program
| or its libraries.
| guerrilla wrote:
| https://en.wikipedia.org/wiki/Return-oriented_programming
|
| I wonder if anyone's ever automated it.
| saagarjha wrote:
| Fully automating ROP is difficult, but people have written
| many scripts to find interesting "gadgets" that set various
| registers and also found useful "targets" to ROP to, such
| as a handful of instructions inside of most libc's system
| command that can yield a shell if jumped to with light
| constraints.
| e12e wrote:
| > you can write a program by "returning" into other bits of
| the program or its libraries.
|
| Phrack has you covered, eg: from 2001:
|
| The advanced return-into-lib(c) exploits: PaX case study by
| Nergal <nergal@owl.openwall.com>
|
| http://phrack.org/issues/58/4.html#article
|
| Think I actually looked at this and an (at the time) recent
| 0day for opensshd that was found and written up by a couple
| of Finnish students - as a motivational presentation for PaX
| and/or grsecurity while at university.
| saagarjha wrote:
| Taken to the extreme, you have ROP:
| https://hovav.net/ucsd/dist/geometry.pdf
| waynecochran wrote:
| If you're exploit using existing code (which would be
| limited), but if you want to inject code you typically need
| to put on the stack. Maybe one could inject code into the
| .bss/.data section, but this is probably protected from
| execution as well. The .text section is probably read only.
| hyper_reality wrote:
| Return Oriented Programming (ROP) can bypass the non-
| executable stack protection, since existing "gadgets" from
| program memory are executed rather than attacker-provided
| shellcode.
|
| However the stack protection will probably require a separate
| information leak (to find the canary value) or arbitrary
| write (to overwrite it) to bypass. Unless the attacker is
| fortunate to find an unprotected function which the compiler
| missed, or a value that can be overwritten which changes the
| control flow and isn't protected by the canary.
|
| ASLR is also a decent mitigation against ROP, and requires an
| information leak so the exploit code can calculate the memory
| offset to find the library gadgets.
|
| In short, ROP isn't the solution to all the mitigations the
| parent posted; in fact ASLR is designed to make ROP harder to
| exploit.
| saagarjha wrote:
| And, if your hardware supports it, PAC and shadow stacks
| can help protect your return addresses too.
| stevekemp wrote:
| Very much so. I wrote a couple of simple "exploiters" for
| particular bad-patterns I saw, shortly after reading this
| piece:
|
| https://steve.fi/security/exploits/
|
| These days these things are less useful, but recreating known-
| exploits is still educational. Once you get buffer-overflows
| handled you can look for more exotic things, format-string
| attacks, and similar.
| e12e wrote:
| Oh, I didn't realize you were based in Finland - and only now
| realized why I've not seen any articles from the Deb adm site
| in a long while:
|
| http://web.archive.org/web/20190325214351/https://debian-
| adm...
|
| Without going too far side-tracked: I think the Arch wiki has
| demonstrated that a community wiki can be very useful - I do
| hope people continue to contribute to the Debian wiki
| (although I find myself mostly on Ubuntu of late).
|
| Anyway, there's a certain path from phrack through debian-
| administration.org that maps out where I find myself today,
| so happy coincidence to see the two line up in the threads.
| navbaker wrote:
| I believe Hacking: The Art of Exploitation comes with a disc
| that has an exploitable image on it.
| ahepp wrote:
| I'm trying to remember where, but I once saw this article
| presented with a very nice guide to replicating the exploits in
| a VM on a modern computer.
|
| I think it must have been in university, unfortunately when I
| look up the course number, the resources seem to be
| (understandably, I suppose) date gated.
| jeffrom wrote:
| I learned so much from this article about how memory works when I
| was starting out, thanks phrack!
| [deleted]
| __abc wrote:
| Being totally immature here, but "Smashing the stack for fun and
| profit" would make a great book title for the Chaturbate memoir.
| ctocoder wrote:
| how I loved trying this in the computer science lab when this 1st
| hit gopher.
| eb0la wrote:
| This and the SYNflood attack are IMHO the best hacking papers I
| ever seen.
|
| This one ages extremely well.
| hyper_reality wrote:
| What a classic! Phrack stopped publishing some time ago but the
| world of security ploughs on, who can recommend similar modern
| resources to Phrack?
|
| Here's a few I'm aware of:
|
| https://www.alchemistowl.org/pocorgtfo/
|
| https://secret.club/
| kdbg wrote:
| While Phrase has stopped, there is the Paper Feed (no generic
| link, just have to link to the latest in the feed)
| http://phrack.org/papers/escaping_from_freebsd_bhyve.html
|
| I think one big change these days is just that more people will
| self-publish their writeups and research. There are also a lot
| more security conferences that people present at some with a
| more narrow focus than the well known conferences too leading
| to more specialty content.
|
| I do a weekly podcast talking just about the latest exploits
| and strategies/research from the last week and pulling content
| for that is basically just following a _ton_ of RSS feeds.
| There is a lot more getting written these days compared with
| the years when Phrack was regularly released. Unfortunately its
| also more spread out and harder to find.
| opticnerve wrote:
| Paged Out - https://pagedout.institute/
|
| Rafale - https://www.rafale.org
| hyper_reality wrote:
| Paged Out is great, Rafale appears to be offline though (and
| French only).
| TrueDuality wrote:
| 2600: https://www.2600.com/
| __jf__ wrote:
| In 2017 I got a second hand Cisco ASA just to play with the
| shadowbrokers tools. EXTRABACON was the codename for the SNMP
| exploit using a buffer overflow.
|
| This was an interesting excercise because there were NO logs of
| this happening on the Cisco ASA, not even when ramping every
| loglevel to debug. Well only on the console port. Exception in
| readline() or something like it. Doing stuff for security
| monitoring in daily life this ehm was alarming, but not
| unexpected. Fixing "No logs" is often a challenge for blue teams.
|
| Anyway it was alarming enough to find and read through the Common
| Criteria EAL4+ certification docs for the Cisco ASA only to find
| that SNMP was excluded from certification scope. I still have the
| idea in the back of my head to explore scope exclusions in other
| certification docs for other unfortunate exclusions.
|
| Also the lack of mitigations like stack canaries, ASLR or others
| was quite surprising for a certified black box security device on
| the network perimeter.
| jnwatson wrote:
| The assumptions about environment and the system-under-test has
| been the Achilles' heel in any certification I've been part of.
|
| It isn't like the CC folks aren't aware of the problem. The
| idea was that the Security Target (definition of the system)
| could declare conformance to a standardized Protection Profile
| which consumers could use as a shortcut to understanding what
| was promised.
|
| However, nobody looks at STs nor PPs except the vendor and the
| certifier, so all that work is for naught. You could absolutely
| get a CC cert with the environment that it is unplugged from a
| network.
| ralph84 wrote:
| Just like almost every FIPS 140 validated crypto module has a
| "FIPS mode" that is what was validated but is never actually
| used in production, even by government customers.
| jnwatson wrote:
| I'm unfortunately quite familiar with that.
|
| Beyond getting slower updates, etc, FIPS mode has the
| unintentional side effect of being the "look at me I have
| interesting stuff" flag for potential attackers. It is
| usually quite easy to determine remotely that a networked
| device is in FIPS mode, too (due to allowed crypto
| protocols, etc).
| maerF0x0 wrote:
| I think the main thing to discuss here is how, 25 yrs later,
| we're still getting overflow bugs.
| saagarjha wrote:
| It's a bit disappointing to still see overflows around, but at
| least blindly smashing the stack is no longer usually
| exploitable for modern systems with basic security.
| somesortofsystm wrote:
| A true classic that is just as relevant today as ever.
|
| Know thy stack!
|
| Yes, you still have a .text section!
| dang wrote:
| 2009 had the main discussion:
| https://news.ycombinator.com/item?id=943185
|
| I thought there were others but maybe not? Single-comment threads
| from 2016, 2014, 2012, 2011:
|
| https://news.ycombinator.com/item?id=11007757
|
| https://news.ycombinator.com/item?id=10821934
|
| https://news.ycombinator.com/item?id=8773298
|
| https://news.ycombinator.com/item?id=4903622
|
| https://news.ycombinator.com/item?id=3061955
___________________________________________________________________
(page generated 2021-01-25 23:01 UTC)