RolfRolles

No, it's really not a strict improvement. A meaningless name like `v2` does at least convey that you, as the analyst, haven't understood the role of the variable well enough to rename it to something more fitting to its inferred purpose. If the LLM comes up with an "informative" variable name that is not very well-suited towards what it actually does, the name can waste your time by misleading you as to the role of the variable.

Yes, gadgets arising from non-epilogue instances of C2/C3 are used frequently. In fact they are most often critical and the ROP exploit would not work without them.

As I said to the other user who replied to a similar comment, these observations apply only to exploitation of stack buffer overflows, and hence don't rebut what I've said about this not mitigating ROP as a general technique (which is also used in the exploitation of non-stack-based vulnerabilities like use-after-free).

Your comments only apply to exploitation of stack buffer overflows, which have largely been rendered extinct due to compiler-based strategies like this one. Exploiting, say, a use-after-free vulnerability still may require ROP but does not require corruption of a return address on the stack. Given that the proposed defense supposedly targets ROP in general and not exploitation of stack buffer overflows specifically, my points still stand.

I also must be missing something. XORing the return address on the stack with the stack pointer is similar to other stack protection mechanisms. I forget the precise name of it, but I'm pretty sure one of the existing stack protection tools does exactly this? MSVC's /GS feature is similar but slightly different in that it XORs the return address with a random value initialized on module load.

However, the claim that ROP is impacted seems a bit flimsy to me. After all, ROP only requires that the C3 (RET) or C2 xx yy (RETN YYXX) byte sequence be present at the end of it; these sequences do occur at the end of a function, but they also occur in other places (such as anywhere the byte C3 arises in compiled machine code). ROP tools are programmed to look for the C3/C2 XX YY sequences and do not know or care whether these sequences are at the end of a function. The post is claiming that by transforming the ends of functions, ROP will be affected; but given that it seems to makes no attempt to remove C3 and C2 bytes from elsewhere in the machine code, that ROP tools will in fact continue to work just fine.

Basically the whole thesis of this patch seems to be that "existing stack protection methods will change function epilogues and therefore break ROP". I don't think it will have much of an effect on existing ROP tools. What am I missing?

I think some timing attacks could be reasoned about in a formal context. You could model the timing details of a given CPU and then prove that two assembly language functions were indistinguishable with respect to that model. (For example, in the case of a comparison function that bailed out early when it found a difference leading to a timing discrepancy, you could replace it with a `for` loop like `for(i = 0; i < size; ++i) mismatch_ctr += src[i] != dest[i]` and then prove that the function takes the same amount of time regardless of whether `src` and `dst` are identical.)

In 2007 I started researching program analysis on my own. I noticed that a lot of freely-available source code was written in OCaml. Then I was supposed to get involved with an academic internship in 2008, where the code was being written in OCaml, so the principal investigator asked me to learn it. I've been coding in it ever since, probably 150,000 lines of code by now. I don't regret taking the road less-traveled. Only now at the end of 2013 am I starting to get curious about Haskell's more esoteric functional programming concepts.

I've tried literally about a dozen times at this point. Only once did I get some sort of response from the server; now clicking "place order" simply does nothing. Too bad; they got all of this publicity at the expense of their target audience not being able to use the service. I hope everyone who was interested remembers to try again tomorrow.

Edit: Alright, I finally succeeded. It took less than three minutes to arrive once my order was placed!

The packaged meal: http://imgur.com/JHrZbTd,WDG574u,2z9KKxn,350v3fd#2 Unwrapped: http://imgur.com/JHrZbTd,WDG574u,2z9KKxn,350v3fd#0

"Carnitas Enchiladas $6.00 Braised Pork with Red Onion and White Cheddar Wrapped in White Corn Tortillas Baked in Red Chile Sauce, Served with Black Beans and Spanish Rice"

What it looks like: http://imgur.com/JHrZbTd,WDG574u,2z9KKxn,350v3fd#1

What it tastes like: Rice: very tasty. Beans: the opposite of tasty; this is actually un-appetizing, and if I was the type to waste food, I would not continue eating it. Enchiladas: doesn't taste bad, but is also not very flavorful.

"Butternut Risotto $6.00 Arborio Rice with Tart Apple, Butternut Squash, Sweet Onion on a Bed of Baby Spinach, with Roasted Cauliflower, and Braised Fennel"

What it looks like: http://imgur.com/JHrZbTd,WDG574u,2z9KKxn,350v3fd#3

What it tastes like: Risotto: tastes mushy, kind of like paste. Caulliflower: doesn't taste bad, but is also not very exciting. Bed of baby spinach: tastes like poison. I don't know how to describe it better, but it tastes terrible.

I guess this is a decent meal for $6.00. It's certainly better than fast food. I have a hard time calling it "gourmet" and I'm not sure if I would order it again. (Living in Berkeley, I am spoiled on the local food, which can be properly considered "gourmet").

Unfortunately, the site does not behave gracefully under heavy traffic. Berkeley resident here, tried to order one of each, but the "place order" page just times out and I am not sure if my order was actually placed, or if I should try again.

Being a reverse engineer who knows what symbolic execution is, is a lonely occupation :( http://www.openrce.org/blog/view/2049/[video]_Semi-Automated...