| 1 |
zorry 10/11/25 20:25:59 |
| 2 |
|
| 3 |
Added: hardened-debugging.xml |
| 4 |
Log: |
| 5 |
added hardened-debugging.xml |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.1 xml/htdocs/proj/en/hardened/hardened-debugging.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/hardened-debugging.xml?rev=1.1&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/hardened/hardened-debugging.xml?rev=1.1&content-type=text/plain |
| 12 |
|
| 13 |
Index: hardened-debugging.xml |
| 14 |
=================================================================== |
| 15 |
<?xml version="1.0" encoding="UTF-8"?> |
| 16 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 17 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/hardened/hardened-debugging.xml,v 1.1 2010/11/25 20:25:59 zorry Exp $ --> |
| 18 |
|
| 19 |
<guide link="/proj/en/hardened/hardenedfaq.xml" lang="en"> |
| 20 |
<title>Gentoo Hardened debugging</title> |
| 21 |
<author title="Author"> |
| 22 |
<mail link="klondike@×××××××××.es">klondike</mail> |
| 23 |
</author> |
| 24 |
<author title="Contributor"> |
| 25 |
<!-- Via bugs #341889 and 265693 --> |
| 26 |
Hugo Mildenberger |
| 27 |
</author> |
| 28 |
|
| 29 |
<abstract> |
| 30 |
In this document we study the ways to do proper binary debugging when using a |
| 31 |
hardened kernel and toolcahin with PaX/Grsec, PIE and SSP. |
| 32 |
</abstract> |
| 33 |
|
| 34 |
<!-- The content of this document is licensed under the CC-BY-SA license --> |
| 35 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> |
| 36 |
<license/> |
| 37 |
|
| 38 |
<version>1.0</version> |
| 39 |
<date>2010-10-26</date> |
| 40 |
|
| 41 |
<chapter> |
| 42 |
<title>Solving the '??' issue.</title> |
| 43 |
<section> |
| 44 |
<body> |
| 45 |
<p> |
| 46 |
When debugging you'll probably have found that <c>GDB</c> may not show the |
| 47 |
addresses showing instead a stream of lines with <e>'??'</e> where the symbol |
| 48 |
should be. This can be caused by two different things. |
| 49 |
</p> |
| 50 |
|
| 51 |
<p> |
| 52 |
The first cause is that your <c>GDB</c> version is too old and is unable to |
| 53 |
realize that the addresses are relative. This should be fixed in the current |
| 54 |
stable versions of <c>GDB</c> so you should try to upgrade it. Other workaround |
| 55 |
is applying solution 3. |
| 56 |
</p> |
| 57 |
|
| 58 |
<p> |
| 59 |
The second reason is that your hardened kernel may be hidding the mappings. This |
| 60 |
is a known problem and <uri |
| 61 |
link="http://forums.grsecurity.net/viewtopic.php?f=1&t=2467" >has been |
| 62 |
fixed upstream</uri> so it will be fixed on further releases of |
| 63 |
<c>hardened-sources</c>. Anyway, until the fix reaches the tree and is |
| 64 |
stabilized, you can apply any of the solutions. |
| 65 |
</p> |
| 66 |
|
| 67 |
</body> |
| 68 |
</section> |
| 69 |
|
| 70 |
<section> |
| 71 |
<title>Solution 1: Disabling RANDMMAP on the binary</title> |
| 72 |
<body> |
| 73 |
|
| 74 |
<p> |
| 75 |
One solution is disabling the RANDMMAP feature with <c>paxctl</c> for that |
| 76 |
particular binary. Doing this will make Grsec disable the mapping protection for |
| 77 |
that binary as it makes no sense protecting it then. This means a more secure |
| 78 |
environment but also getting away from the way the binary would be executed on |
| 79 |
the real environment. |
| 80 |
</p> |
| 81 |
|
| 82 |
<pre caption="Disabling RANDMMAP with paxctl."> |
| 83 |
# <i>paxctl -r binary</i> |
| 84 |
</pre> |
| 85 |
|
| 86 |
</body> |
| 87 |
</section> |
| 88 |
|
| 89 |
<section> |
| 90 |
<title>Solution 2: Disabling the option to hide mappings</title> |
| 91 |
<body> |
| 92 |
|
| 93 |
<p> |
| 94 |
Other fix is disabling the option that hides the addresses on the PaX protected |
| 95 |
executables to avoid attacks based on that information. This option may make |
| 96 |
the things easier for an attacker until it is enabled again although also means |
| 97 |
that the environment will be the most similar possible to the real execution |
| 98 |
environment. |
| 99 |
</p> |
| 100 |
|
| 101 |
<pre caption="Disabling the mapping hiding."> |
| 102 |
Address Space Protection ---> |
| 103 |
[ ] Remove addresses from /proc/<pid>/[smaps|maps|stat] |
| 104 |
</pre> |
| 105 |
|
| 106 |
</body> |
| 107 |
</section> |
| 108 |
|
| 109 |
<section> |
| 110 |
<title>Solution 3: Linking a non PIE binary</title> |
| 111 |
<body> |
| 112 |
|
| 113 |
<p> |
| 114 |
A last solution is disabling the last pie linking stage while compiling using |
| 115 |
<c>-nopie</c>. All previous compilation can still use <c>-fPIE</c> as normal |
| 116 |
(which is also the default with the hardened compiler) so that your executable |
| 117 |
is as close as possible to the real thing as long as the final link must create |
| 118 |
a regular executable. |
| 119 |
<br /> |
| 120 |
Try adding <c>-nopie</c> to LDFLAGS if you're building with emerge. |
| 121 |
</p> |
| 122 |
|
| 123 |
</body> |
| 124 |
</section> |
| 125 |
</chapter> |
| 126 |
|
| 127 |
<chapter> |
| 128 |
<title>Using breakpoints</title> |
| 129 |
<section> |
| 130 |
<body> |
| 131 |
|
| 132 |
<p> |
| 133 |
You may find that PaX may prevent <c>GDB</c> from setting software breakpoints, |
| 134 |
depending on how the kernel is configured. This includes the breakpoint at main |
| 135 |
which you need to get started. There are two workarounds with different |
| 136 |
effects and constraints to to solve this. |
| 137 |
</p> |
| 138 |
|
| 139 |
</body> |
| 140 |
</section> |
| 141 |
|
| 142 |
<section> |
| 143 |
<title>Solution 1: Removing the RANDEXEC and MPROTECT flags</title> |
| 144 |
<body> |
| 145 |
|
| 146 |
<p> |
| 147 |
The first solution is making PaX disable the RANDEXEC and MPROTECT features |
| 148 |
for the binary to be debugged. To do this you have to set with <c>paxctl</c> the |
| 149 |
<c>m</c> and <c>x</c> flags on the executable. The <c>x</c> flag is set by |
| 150 |
default, so it should suffice to do: |
| 151 |
</p> |
| 152 |
|
| 153 |
<pre caption="Disabling MPROTECT"> |
| 154 |
# <i>/sbin/paxctl -m binary</i> |
| 155 |
</pre> |
| 156 |
|
| 157 |
<p> |
| 158 |
After that <c>GDB</c> should be able to add software breakpoints on the binary, |
| 159 |
if it still can't try disabling the SEGMEXEC and PAGEEXEC features (flags |
| 160 |
<c>s</c> and <c>p</c> respectively). |
| 161 |
</p> |
| 162 |
|
| 163 |
<pre caption="Disabling SEGMEXEC and PAGEEXEC"> |
| 164 |
# <i>/sbin/paxctl -ps binary</i> |
| 165 |
</pre> |
| 166 |
|
| 167 |
<p> |
| 168 |
Below we'll expose what's happening on a lower level when you add a software |
| 169 |
breakpoint, and why PaX disallows this. You need to know a bit about how |
| 170 |
processors work in order to understand it. This is not needed to solve your |
| 171 |
problem so feel free to ignore it. |
| 172 |
</p> |
| 173 |
|
| 174 |
<p> |
| 175 |
When the debugger adds a soft breakpoint it changes the instruction on the |
| 176 |
executable memory image so it is a breakpoint instruction (on x86 and amd64 |
| 177 |
they are the <c>bp</c> and <c>bu</c> instructions). This instruction halts the |
| 178 |
processor and gives the control back to the debugger and has the advantage |
| 179 |
that it can be set in an unlimited number of points on the program. As PaX |
| 180 |
disallows writes in executable memory for security reasons it is impossible for |
| 181 |
the debugger to modify the code and add the breakpoint. |
| 182 |
</p> |
| 183 |
|
| 184 |
</body> |
| 185 |
</section> |
| 186 |
|
| 187 |
<section> |
| 188 |
<title>Solution 2: Using hardware breakpoints</title> |
| 189 |
<body> |
| 190 |
|
| 191 |
<p> |
| 192 |
Another solution is using hardware breakpoints, they don't require any changes |
| 193 |
on PaX behavior, but they are usually limited (for example to a maximum of 4 on |
| 194 |
x86 and amd64 including address watchpoints) and also have the problem that they |
| 195 |
require the program to be already running in order to be added (although there |
| 196 |
is some WIP to fix this in <c>GDB</c>). |
| 197 |
</p> |
| 198 |
|
| 199 |
<p> |
| 200 |
To use them just use the <c>hbreak</c> instead of the <c>break</c> command. |
| 201 |
</p> |
| 202 |
|
| 203 |
<p> |
| 204 |
Below we'll expose what's happening on a lower level when you add a hardware |
| 205 |
breakpoint. You need to know a bit about how processors work in order to |
| 206 |
understand it. This is not needed to solve your problem so feel free to ignore |
| 207 |
it. |
| 208 |
</p> |
| 209 |
|
| 210 |
<p> |
| 211 |
When the debugger adds a hardware breakpoint it changes some of the |
| 212 |
processor registers (on x86 and amd64 they are the Dr registers) so the |
| 213 |
processor halts when a certain address is accessed (either for reading, writing |
| 214 |
or execution). As a result this implies that no data has to be written in |
| 215 |
memory solving the soft breakpoints problem, but also limits the number of |
| 216 |
available breakpoints. |
| 217 |
</p> |
| 218 |
|
| 219 |
</body> |
| 220 |
</section> |
| 221 |
</chapter> |
| 222 |
|
| 223 |
<chapter> |
| 224 |
<title>Restoring the file after debugging</title> |
| 225 |
<section> |
| 226 |
<body> |
| 227 |
|
| 228 |
<p> |
| 229 |
After debugging you may want to restore the system to its normal state, if you |
| 230 |
used <c>paxctl</c> you can reset the flags to default using the <c>-z</c> flag. |
| 231 |
</p> |
| 232 |
|
| 233 |
<pre caption="Reseting the flags back to its defaults."> |
| 234 |
# <i>paxctl -z binary</i> |
| 235 |
</pre> |
| 236 |
|
| 237 |
</body> |
| 238 |
</section> |
| 239 |
</chapter> |
| 240 |
</guide> |
Archives