-1

In Linux, with ASLR enabled, is there a range of addresses where user stack address lies? What about heap, instruction addresses(text section)? In general, is it possible to look at an address and tell if it is for data or for code?

Edit: I am trying to write a Pintool that looks at the EIP after a return and checks if the EIP points to a data area. Let's assume that NX is not enabled on this system.

For some reason, this was downvoted. Fortunately, the answer can be found here: https://security.stackexchange.com/questions/185315/stack-location-range-on-linux-for-user-process/185330#185330

abjoshi - Reinstate Monica
  • 372
  • 1
  • 13
  • What problem are you trying to solve with this information? Why would a program care which range of addresses are used? Are you trying to write an exploit that gets around ASLR? – Barmar May 05 '18 at 11:36
  • No, quite the opposite actually:-). I am trying to write a Pintool that looks at the EIP after a return and checks if the EIP points to a data area. Let's assume that NX is not enabled on this system. – abjoshi - Reinstate Monica May 05 '18 at 19:27
  • Why the downvote? Kindly explain. – abjoshi - Reinstate Monica May 06 '18 at 09:37
  • I didn't downvote, but you should read [how-to-ask] to see how to write a good question. There needs to be some code you've written that you're having trouble getting to work properly, so we can help you fix it. Questions about the design of Linux are more appropriate for [linux.se]. – Barmar May 07 '18 at 17:23
  • @Barmar, actually, I believe in this case, it is possible to provide advice without looking at code. See "https://security.stackexchange.com/questions/185315/stack-location-range-on-linux-for-user-process/185330#185330" . I have asked the same question there and have received helpful replies. I will put an edit here for the answer link. – abjoshi - Reinstate Monica May 07 '18 at 22:50

1 Answers1

1

cat /proc/self/maps will show the initial location of the main thread's stack. This can be inaccurate for (at least) the following reasons:

  • you're not in the main thread
  • any part of the program was built with the -fsplit-stack option, or you call a library that does something similar
  • you're within a signal handler that requests the sigaltstack stack instead
  • you do weird alloca tricks like CHICKEN Scheme does to use the stack as a heap
  • ...

Also note that the general areas are not fully random. See the AddressSanitizer project for something that takes advantage of this.

o11c
  • 15,265
  • 4
  • 50
  • 75
  • Hi, I have 2 followup questions: 1. Instead of sanitizing for stack locations, can I instead do it for the text section, i.e check if an addr in EIP after ret is indeed a valid instruction from the instruction area. I wonder there are corner cases like the above in this case. – abjoshi - Reinstate Monica May 08 '18 at 10:33
  • 2. How about this situation: Say NX bit is enabled and I need to prevent ROP. Then the above approach will fail as the EIP will always be valid. In this case, I would try to prevent next step, i.e. stack pivoting. So now, a reasonable(not fool-proof) strategy would be to check if the location in the (corrupted)SP value is a sane value from the stack.(and not from the heap or any other section). Any leads as to how to solve this problem? – abjoshi - Reinstate Monica May 08 '18 at 10:38
  • I've already answered the text section question here: https://stackoverflow.com/a/37984639/1405588 ... the rest is a complex question that should be asked separately, and I can't help except that normally when a canary is killed, so is the whole process. – o11c May 08 '18 at 18:55