<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Thank you very much for your contribution Bernd, I fully agree with all what you said. C language is a problem, but it is also a standard. Correcting efficiently C language « weaknesses » like intensive stack usage cannot be achieved securely through software technics : StackShield and StackGuard technics have partly failed, and they don’t block ROP exploitation.<div><br></div><div>Let’s say that for the first version of the secure processor, the main goals were to « cancel » by design, from the hardware :</div><div><br></div><div>- Stack Overflow security breach.</div><div>- Buffer Overflow security breach.</div><div>- ROP exploitation technics.</div><div><br></div><div>It has been more than one year study to find the tricks to do it definitly.</div><div><br></div><div>The planned next step, in the future, are to block the « Interger Overflow » familly security breach, and reaching the goals you are talking about.</div><div><br></div><div>We already found a way to do it, but unfortunatly it won’t be available in the first version, because this time, its implementation in VHDL requires a lot of work.</div><div><br></div><div>But as far as we know, this last family of security breach « Interger Overflow » should be completly solved.</div><div><br></div><div>For now, with the current design of the architecture of the processor, we partialy « cancel » it. Some would say what we are doing is enough to solve the problem, but I think it would really worth it to implement our full solution so that we could ensure that they are definitly stopped.</div><div><br></div><div>Then, about TOR Routers :</div><div><br></div><div>Yes : Once again, I fully agree with you. One of the most efficient strategies to achieve security is simplification. This is why our goal with Linus would be to have TOR running without any OS to reduce the attack surface.</div><div>Of course, we still need to link the code with some libraries like SSL and a TCP/IP stack, but understand that with no possibility to use the security breach mentionned above, any « standard low level attack » on this, even if not perfect (Containing overflows) would be blocked.</div><div><br></div><div>This is to me already a huge step forward.</div><div><br></div><div>I’m looking forward to hearing from you.</div><div><br></div><div>And thank again for your contribution.</div><div><br></div><div>PS : This secure processor project is an open project. I you are interested in it, feel free to join the team. Any kind of contribution like your last post is very welcome.</div><div><br></div><div>Kind regards,</div><div><br></div><div>@Stman.</div><div><br><div><div>Le 2 août 2014 à 19:27, Bernd Paysan <<a href="mailto:bernd@net2o.de">bernd@net2o.de</a>> a écrit :</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Am Samstag, 2. August 2014, 18:41:19 schrieb ★ STMAN ★:<br><blockquote type="cite">Hello Randy,<br><br>Yes.<br><br>With Linus (TOR Team), we are having two goals :<br><br>- Find a suitable development environment to implement secure TOR routers<br>with 100% self made electronics (The closed path to this goal is using FPGA<br>(That are NSA backdoored sometimes: The JTAG module can be remotly<br>controled with top secret hidden channels)) using FPGA and self design<br>processors / peripherals (Ethernet Port, Memory controllers, USB<br>Controller, PCIe bus, serial ports, etc..: Let’s say a self made SoC) in<br>VHDL : This is the best solution we have to get as much control of the<br>hardware as possible, and then port a self-made IP Stack inside this<br>environment and also port the TOR daemon routines in this environment : In<br>order to reduce the software attack surface, we exclude, for now, using ANY<br>KIND OF OS, as long as for such particular application where we just need<br>to implement a TCP/IP stack and a few other things, is it not necessary to<br>have an embedded OS. Doing so, we are drasticaly reducing the attack<br>surface of the whole system : The hardware, and the software attack surface<br>too.<br></blockquote><br>If you want to have a drastically smaller attack surface, you also need to go<span class="Apple-converted-space"> </span><br>drastically simpler. That probably means not using TOR as it is now (with SSL<span class="Apple-converted-space"> </span><br>over TCP, both pretty complex protocols of their own), but a protocol where<span class="Apple-converted-space"> </span><br>you can do the secure routing (mostly) in hardware.<br><br><blockquote type="cite">We will use a new generation of self-made microprocessor architecture that<br>is able, by design, to stop ALL THE LOW LEVEL security breach family :<br>Stack Overflow, Buffer Overflow (And all their cousins: Integer Overflow),<br>but also, the most dangerous low level way of exploiting such low level<br>security breach : ROP (Return Oriented Programming). This new processor<br>also stops by design all ROP exploits.<br></blockquote><br>IMHO, that stuff is mostly a language problem: The C language has several mis-<br>features which result in an unified stack, arrays not being first-class (which<span class="Apple-converted-space"> </span><br>means functions don't know how big a buffer is unless explicitely passed as<span class="Apple-converted-space"> </span><br>additional, unrelated parameter) and so on. That's something that can be<span class="Apple-converted-space"> </span><br>solved:<br><br>* The language must pass arrays as addr+len pairs to be able to perform checks<span class="Apple-converted-space"> </span><br>- the only "pure" pointer without size maybe is the function pointer.<br><br>* Parameter stack, return stack and the stack for local buffers must be<span class="Apple-converted-space"> </span><br>separated (different registers), and the language must have a native way to<span class="Apple-converted-space"> </span><br>return more than one argument without resorting to pointers (which then opens<span class="Apple-converted-space"> </span><br>up holes by writing something bigger into the pointer passed).<br><br>* The memory overwriting flaws are IMHO the most important to fix. The<span class="Apple-converted-space"> </span><br>integer overflow stuff can be partly dealt with in hardware (trap on overflow<span class="Apple-converted-space"> </span><br>for signed, trap on carry for unsigned), but not completely (sometimes you<span class="Apple-converted-space"> </span><br>simply want the integers to wrap around and it's perfectly fine).<br><br>A high level language like Python can do a good job on the overflow side, but<span class="Apple-converted-space"> </span><br>a low level language will have difficulites. And the high level language<span class="Apple-converted-space"> </span><br>eventually is implemented in the low level language, and some parts of the<span class="Apple-converted-space"> </span><br>system have to use the low-level parts, so there's no way around having a low-<br>level language that does at least the most important things right (buffers and<span class="Apple-converted-space"> </span><br>stacks).<br><br>--<span class="Apple-converted-space"> </span><br>Bernd Paysan<br>"If you want it done right, you have to do it yourself"<br><a href="http://bernd-paysan.de/">http://bernd-paysan.de/</a></div></blockquote></div><br></div></body></html>