Nytro

Din partea mea, daca zbori de aici, nu mai dai DDOS, si nu mai vad rspula aici, e ok, sunt de acord sa nu iti fie facute datele publice. Oricum nu e nevoie, totul se gaseste la simple cautari pe Google sau aici pe forum. PS: Nu stiu cine da DDOS site-ului tau, dar asa vezi si tu ca nu e frumos.

Din cate am inteles eu le-a CERUT el 300 de dolari, i-au dat banii, apoi i-a santajat ca daca nu ii dau 3000 de dolari ii fac datele publice. Ce contract bre? Oricum mi se rupe de cazul respectiv. Din partea mea datele trebuiau facute publice pentru ca a dat DDOS, atunci.

In mod normal nu sunt deloc de acord ca unui membru sa i se face datele publice pentru ShowOff, malware (non-banking) etc. dar cum baiatu' este cel care ne dadea DDOS... In plus, daca povestea cu 300 si 3000 de dolari este adevarata... Lipsa de etica. PS: Si-a postat in trecut niste date aici pe forum, public.

Muie, Steaua!

Acum merge. Nu sunt foarte detaliate, dar sunt ok. Materie de facultate, nu poti avea pretentii de la asa ceva. Thanks.

Nu stiu ce s-a intamplat, dar Gecko are dreptate pentru ca e moderator. RST's logic.

Sunteti prea activi aici. Topic inchis.

Cine mai comenteaza de-a-n-pulea are ban.

Va place sa comentati la toate cacaturile...

Sa imi ziceti daca mai patiti asta. Puneti un Wireshark daca se intampla si salvati pcap-ul.

Asa cum au bagat nu stiu cate milioane de euro intr-un portal de cacat, ma astept la asa ceva. Comunistii astia sunt chiar retardati. E spalare de bani, pe fata.

"Valoarea total? a proiectului s-a ridicat la 17.881.980 de lei, dintre care 15.199.683 de lei au fost achita?i din Fondul Social European" Sa-i fut in inima. Sa ii futa cineva, sa le dea deface si sa faca toate datele publice. Sa-si bage programu' prin capu pulii si sa il scoata pe cur. Ce firma a realizat acel program? De catre cine e condusa?

Uber kewl!

Nu va alegeti username-uri drept cuvinte cheie sau nume de functii (@mysql_connect de exemplu)

In sfarsit o informatie utila. Aveti AVG? Aveti Chrome? Toti? De pe Mozilla nu merge?

Ban. Nu va mai abateti de la subiect.

Babelor, veniti in cacat si cu niste detalii tehnice, inca nu mi-am reparat globul de cristal sa stiu de ce nu va merge. 1. La ping in gateway aveti raspuns? 2. DNS-ul e rezolvat corect? 3. Alte site-uri va merg (fara sa fie din cache)? 4. La ping raspunde RST? 5. La traceroute ajunge pana la server? 6. Se realizeaza conexiunea? 7. Se conecteaza pe portul 80? 8. Site-urile de "is this site down just for me" zic ca e down? 9. Cu un proxy va merge? 10. Cu Tor va merge? 11. De pe telefon (internet mobil) va merge? Completati formularul de mai sus macar.

Daca aveti probleme pe forum va recomand sa discutati cu em. El este cel mai de treaba si daca il rugati frumos si va tineti de capul lui o sa va ajute. Noi ii zicem "good guy em".

E "self" sau se poate executa si la altii?

Banuiesc ca te referi la "struct"-ul din C/C++. E simplu, sa luam un exemplu: 1. Un int, de obicei, se memoreaza pe 4 octeti 2. Un char se memoreaza intotdeauna pe 1 octet 3. Un float, de obicei, are 4 bytes Astfel, putem crea o structura compusa din mai multe campuri: struct Om // Sau typedef struct Om{ int varsta; float inaltime; }; O structura are avantajul de a grupa niste date care definesc un "obiect" (In C++ o structura chiar defineste un obiect, la fel ca si cuvantul "class"). In C doar se grupeaza niste date, in C++ insa "struct" este identif cu "class" cu exceptia faptului ca implicit in struct datele sunt "public" iar in class sunt "private". Nu te stresa cu aceste aspecte, le vei invata pe parcurs cand vei invata C++. Pentru inceput e de ajuns sa intelegi ca asa se pot grupa niste date. Astfel poti defini un obiect de tipul "Om", la fel cum definesti un "int". Om variabila_de_tipul_Om; // Sau 'struct Om variabila_de_tipul_Om;' int variabila_de_tipul_int; // Variabila simpla Cu variabila de tipul "Om" poti accesa datele astfel: variabila_de_tipul_Om.varsta = 12;variabila_de_tipul_Om.inaltime = 1.80; Si cam asta e tot. Daca datele sunt alocate dinamic, se schimba putin lucrurile: Om *variabila_de_tipul_Om_C = (Om *)malloc(sizeof(Om)); // Aloci, in C, spatiu pentru o structura de tipul OmOm *variabila_de_tipul_Om_CPP = new Om; // Aloci si apelezi contructorul (nu te intereseaza asta deocamdata) in C++ Iar pentru accesarea datelor: variabila_de_tipul_Om->varsta = 12;variabila_de_tipul_Om->inaltime = 1.80; Un lucru de care trebuie sa tii cont cand folosesti structuri e dimensiunea structurii: struct Test{ int x; // 4 bytes char y, z; // 2 bytes, cate unul fiecare } Desi in mod normal structura ar avea 6 bytes, de cele mai multe ori compilatorul "aliniaza memoria" la multipli de 4 octeti. Astfel este posibil ca dimensiunea structurii sa fie de fapt 8 octeti. De aceea e bine sa folosesti intotdeauna operatorul "sizeof" pentru a determina dimensiunea oricarui tip de date.

DEFCON 19: Bit-squatting: DNS Hijacking Without Exploitation (w speaker) Speaker: Artem Dinaburg Security Researcher, Raytheon We are generally accustomed to assuming that computer hardware will work as described, barring deliberate sabotage. This assumption is mistaken. Poor manufacturing, errant radiation, and heat can cause malfunction. Commonly, such malfunction DRAM chips manifest as flipped bits. Security researchers have known about the danger of such bit flips but these attacks have not been very practical. Thanks to ever-higher DRAM densities and the use of computing devices outdoors and in high-heat environments, that has changed. This presentation will show that far from being a theoretical nuisance, bit flips pose a real attack vector. First the presentation will describe bit-squatting, an attack akin to typo-squatting, where an attacker controls domains one bit away from a commonly queried domain (e.g. mic2osoft.com vs. microsoft.com). To verify the seriousness of the issue, I bit-squatted several popular domains, and logged all HTTP and DNS traffic. The results were shocking and surprising, ranging from misdirected DNS queries to requests for Windows updates. The presentation will show an analysis of 6 months of real DNS and HTTP traffic to bit-squatted domains. The traffic will be shown in terms of affected platform, domain queried, and HTTP resources requested. Using this data the presentation will also attempt to ascertain the cause of the bit-flip, such as corruption on the wire, in requestor RAM, or in the RAM of a third party. The presentation will conclude with potential mitigations of bit-squatting and other bit-flip attacks, including both hardware and software solutions. By the end I hope to convince the audience that bit-squatting, and other attacks enabled by bit-flip errors are practical and serious, and should be addressed by software and hardware vendors.

Gay-protestele din Romania: http://media.hotnews.ro/media_server1/image-2013-09-6-15520562-0-protest-impotriva-proiectului-rosia-montana.jpg Sa razi cu jandarmii? Ala e protest? Sa-i futi in inima de jegosi, pentru 8 milioane/luna si-o muie ii apara pe cacatii de la putere. Romanii sunt prosti, fricosi si cel mai important: doare-n-cur-isti. I se rupe lor de tara, apoi se plang la samanta in fata blocului ca tara e de cacat. Ei sunt de cacat. Cand trebuie sa se iasa in strada, sa se iasa, ca si in Ucraina. Tot respectul pentru ucrainieni. Si acum se vede clar cat de imputiti pot fi jandarmii, politistii si soldatii. Folosesc armele impotriva propriului popor. Printre protestanti ar putea fi familiile lor. Cat de muist sa fii sa faci asta? Pentru 8 milioane si-o pula-n cur? Nu se zice degeaba ca gaborii sunt prosti.

[h=2]Applied Reverse Engineering with IDA Pro[/h] This editorial is committed to subverting the essential security restriction mechanisms of a native binary executable by employing the IDA Pro Dissembler. This paper is basically elaborating a very complex mechanism of reverse engineering among the previously demonstrated papers, yet because it is a very exhaustive and long process, it claims epic proportions of patience and proficiencies in Machine code instructions — but it is very interesting and challenging. We have mostly focused on .NET reverse engineering so far, which is relatively an easy task, instead of native binary reversing, because the source code is straightforwardly manipulated by dissemblers. This article would surely assist the aspirants who are repeatedly seeking a step by step tutorial on IDA Pro reverse engineering, because no such paper is perfectly crafted in laborious fashion so far. This article showcases the particulars of these contents: Live Binary Sample Target Target Analysis with IDA Pro Cracking the Target Alternative way of Tracing Final Note There are ‘n’ numbers of approaches for reverse engineering, and picking the appropriate one depends on the target program, the platform on which it runs and on which it was developed, and what kind of information you’re seeking to extract. Generally speaking, there is one fundamental reversing methodology: offline analysis, which is all about taking a binary executable and using a disassembler to convert the machine code into a human-readable form. Reversing is then performed by manually reading and analyzing parts of that output. Offline code analysis is a powerful approach because it provides a good outline of the program and makes it easy to search for specific functions that are of interest. The disassembler is one of the most significant reverse engineering apparatuses. Essentially, a disassembler decodes binary machine code into a readable assembly language code. The disassembler merely decodes each instruction and creates a textual representation for the code. It is trivial to say, the specific instruction encoding format and the resulting textual representation are entirely platform-specific. Each platform provides a different set of instructions and registers. Therefore a disassembler is also platform-specific (even though there are a couple of disassemblers that contain specific support for multiple platforms). Essential The target file IDA Pro Interactive Dissembler PE signature verifier Assembly Language skills Live Binary Sample Target This time, I have chosen a target binary which is being applied over reverse engineering, and its origin is in fact totally unknown to us. This executable basically first validates the user identity by asking the password. If user enters the correct information, then he would be able to proceed; otherwise it echoes the wrong password message over the screen. But we have obtained this binary from some unauthentic sources. Thus we are not provided with the user password token key which would probably have part of a license key. Luckily, we have only the executable, not the source code, so that we can figure out the mechanism implemented behind the scenes. Figure 1.1 So the only possibility left to carry on without buying the license code is to reverse engineer this binary file using IDA Pro dissembler. It is indispensable to confirm either this target binary is a standard Windows PE file or belongs to some other platforms, because it is mandatory for a binary file to have the PE file signature; otherwise, IDA Pro won’t dissemble it. So to achieve this, we can assist PE Explorer to obtain the signature information of this binary as follows in the file Header section. Figure 1.2 The aforesaid figure clearly expresses that this binary has a Windows PE signature and hence could be dissembled by IDA Pro, which we are going to elaborate in the next section. Target Analysis with IDA Pro Well, we have obtained the origin information of the target file so far using PE explorer. As we have stated earlier, reversing with IDA Pro is truly a laborious task, because we have to encounter trivial machine code. We don’t have the source code, rather only the binary executable. However, we first decompile or dissemble the binary using IDA Pro in order to comprehend what mechanics are implemented implicitly. Thus, launch the IDA Pro software, and it will ask to choose the prototype of a new disassemble file: Figure 1.3 After configuring the disassemble prototype as a new project, the IDA prompts to open the target binary as in the following figure. Figure 1.4 Right after choosing the target file, IDA Pro displays a screen dialog which stated three type of a file to be reversing as PE File, DoS Executable File, and Binary file. These file types basically point out the platform on which they were developed. In our scenario, the PE file is best fit-in because we have chosen a Windows 32 console application as per the figure 1.2; Apart from that, we can organize other option such as processor type, kernel and DLL renaming as follows: Figure 1.5 Finally, click OK. Don’t bother ahead because IDA Pro prompts a couple of alert messages, open in two different dialog windows. On the whole, much internal processing is done before opening a target file. As you can grasp the RED BOX in the following figure 1.6, we have a function window which enumerates all the methods and routines used in this executable. The graph window creates the control execution in flow chart format stated in the RED BOX. It provides a drag-able and moveable dashed rectangle box which can let us reach anywhere in the code execution. In the BLUE BOX, it shows the decompile code in assembly code format and most importantly, we can access any segment of code such as entry point, containing text string, binary pattern and marked position just by dragging the pointer in the first RED BOX. Figure 1.6 The important point to note here is that the Debugger menu would only be visible if the target file has the correct PE signature; otherwise it remains invisible. That’s why is better to identify first the signature of the target file using PE explore. We shall accomplish the task of logic tracing by debugging the decompiled file. We however choose the appropriate debugger. In our case, we pick Local Win32 debugger as follows: Figure 1.7 After ensuring the mandatory configuration, it is time to correlate with the actual mechanism by using the arrow mentioned in the following figure 1.8; it basically requires some hit and trail to find out the actual execution code path by dragging the pointer. The alert string message mentioned in figure 1.1 assist us to figure out the execution path. In fact, this target file shows numerous execution paths, and some of them are useful in the context of reversing, and the remaining ones are useless. So, the code flow that shows the alert message “Enter the password” is very significant to the reversing point of view, because this is the key value or entry point by which we can trace the essential code. Figure 1.8 After moving the pointer to a specific location, we can find the actual mechanism logic flow as following. It typically shows the control flow when we enter the wrong password value. Figure 1.9 The logic path flow mentioned in the aforesaid figure usually does not fit in the work area window. For this purpose, we can move the dashed rectangle in the graph overview by dragging it to reach a specific segment as follows: Figure 1.10 After moving the pointer to the appropriate location, we have found the decompiled code in assembly language format. Here, we can easily assume that this program prompts the user to enter the password by the scanf method mentioned in the RED BOX. Then this value is compared to a predefined string value (which is password) using the strcmp method. The test eax register is holding the value 0 or 1 which would come based on the string comparison. Finally, the jnz instructs the compiler to directly jump to the false segment branching, which is location 411444. Figure 1.11 If the eax register contains the value 0, then the condition would be true and the code execution directed to the box highlighted by cyan color. If it has a value of 1, then the control flow diverts toward the false condition block as follows: Figure 1.12 If the user enters the correct password, the following assembly code segment would be executed, in which first the “congratulations” message would be displayed along with the actual password information as follows: Figure 1.13 As we have stated earlier, the code flow instructions are huge in quantity, so we have to move the dashed rectangle from time to time in order to reach the specific code block. This time we move to a false condition block as follows: Figure 1.14 If the eax register doesn’t contain the value 0, then the execution is diverted toward the following figure block where the “Wrong Password! Try again” message will be print on the screen as shown below. Figure 1.15 Finally, no matter what value the eax register holds, the compiler always executes the following assembly instruction, where the getch method is encountered every time as follows: Figure 1.16 So, we have successfully disassembled the target assembly code to correlate to the actual mechanism running behind the scenes. We have come to a conclusion that the eax register value is the key hack. If its value is 0, then we entered into the true condition code block; otherwise we entered into the false condition block. Cracking (Reversing) the Target So, the eax register value would be the key interest for the reverser to subvert the password mechanism. If we change that value manually during debugging, then we can reach the true condition block even if we enter the wrong password information. In this encounter, our leading objective is to collapse the jump statement (jnz) execution so that the calling of method loc_411444 won’t happen. To do so, run this application in debugging mode. However, place a breackpoint at eax instruction by using F2. The instruction would be submerged in red box as follows: Figure 1.17 Then, run this executable by Start Process (F9) from Debugger. Again, a couple of windows appeared, then disappeared as usual. Figure 1.18 After that, the target starts to execute in DoS mode, because it is a console application. Here, it asks the user to enter the password as per its functionality, but unfortunately we don’t have the password. So, just enter any value as a password and press enter. Figure 1.19 The moment we press enter after entering the bogus password value as test, the execution is transferred to the IDA View-A, and we reach the instruction where we placed the breakpoint earlier. Then we have to move ahead manually by pressing the step into (F7) and we step forward to the jump instruction. Here, we notice that the green arrow (in the RED BOX) started blinking, which points out that the execution is about to transfer to the B31444 method block. If we didn’t do anything, the wrong password message display as usual. Figure 1.20 The execution is transferred to B31444 (false condition) block because eax register has a value as 1. The transmission to the false condition block happens due to the ZF value as 0. If this value would have 1, then the true condition block would execute. Figure 1.21 However, if we modify the value of ZF to 1, then we could control the code path execution to a true condition block. In order to change this value, right click over value and select Modify value as: Figure 1.22 Here, just replace the ZF register value from 1 to 0 and click OK. Figure 1.23 The moment the ZF register value is changed to 1, we notice that the execution flow is instantly changed to the true condition block by repeatedly blinking the red arrow in the BOX as follows: Figure 1.24 Now, go to the Debugger menu and press the Run until return option, which ends the execution after reaching the end of the code. Bingo!!! The target binary is showing the congratulation message even if entering the wrong password value. In addition to that, this program shows the original password value as ajay. Figure 1.25 So, we successfully subvert the password security mechanism just by diverting the binary code flow execution. But to get rid of a common misconception, we have to reverse engineer this target file, which is actually not patched. The password restriction is still in place, because we have not modified the corresponding bytes so far. Alternate way of Tracing Identification of the program entry point is always complex in IDA Pro because it shows raw assembly code. We have applied such a process by moving the arrow as in Figure 1.8. But this is a very cumbersome task. There is another way which eases the task of identifying such entry points. A program displays some string to carry on the execution ahead or to assist the user to control the execution. Just consider the following figure: It asks the user to enter the password by prompting the “Please enter the password” string. Figure 1.26 This string could be beneficial in terms of finding the entry points. So go to Text search and enter this string in the box, which finds such entries in the assembly code as follows: Figure 1.27 Alternatively, the string window displays all the in-built strings value of the target program. Just double click over the “Please enter the password” string, which redirects us to its assembly code. Figure 1.28 Here, we didn’t find the code execution in flow chart format, but in actual assembly code. So we reached the location where the string is located. Place the breakpoint here by F2 as earlier. Therefore, follow the operation or steps as performed earlier from Figure 1.18: Figure 1.29 Final Note This rare piece of information illustrated the process of disassembling as well as reverse engineering tactics over a native binary by using IDA Pro disassembler. We have seen the importance of the register values of binary code to correlate with actual program implementation and what role they can play in the reversing process. We have subverted the password mechanism just by modifying the value of the ZF register, which is connected to the eax register. The tutorial that applies to the binary target is dedicated to reversing the logic flows only, not patching the byte code associated with mechanism. There is no permanent change in memory related bytes; if we run this target again without IDA Pro, the password mechanism is still there, and it is not bypassed yet. We will discuss byte patching in detail in the next article. By Ajay Yadav|February 17th, 2014 Sursa: Applied Reverse Engineering with IDA Pro - InfoSec Institute

Taking Control of Linux Exploit Mitigations By Will Dormann on 02/17/2014 | Permalink Hey, it's Will. In my last two blog entries, I looked at aspects of two exploit mitigations (NX and ASLR) on the Linux platform. With both cases, Linux left a bit to be desired. In this post I will explain how to add further exploit protections to Linux. If you want to be secure in the Windows world, you should be running Microsoft EMET. If you are running Windows Vista or later, EMET mitigates nearly the entire class of memory corruption vulnerabilities by using DEP, ASLR, ROP, and other mitigations. A tool like EMET is possible because, with Windows, ASLR can be enabled for programs and libraries that weren't explicitly built to support it. Edit: While the set of exploit mitigations provided by EMET can be applied per application in Windows, ASLR will only be applied to the libraries loaded by the application. If an application is not linked with /DYNAMICBASE, then the load address of the application itself will not be randomized with EMET's application-specific mitigations. If EMET is used to enable system-wide ASLR, then executables with a relocation table are randomized. Executables with no relocation table, such as those linked with /FIXED, will not be randomized, regardless of how EMET is configured. Sometimes things can break when EMET is used though. When these situations arise, the options are to either disable specific mitigations for certain applications or wait until vendors fix their code. With Linux, things aren't so easy. As I described in my previous blog post, an executable must be compiled with PIE to be ASLR compatible. By default, most applications on Linux are not compiled with PIE. A simple visualization of ASLR on Linux can be achieved by running the following command multiple times: cat /proc/self/maps Running this command displays the memory maps for the current process, which is cat in the above case. First let's look at the default UbuFuzz virtual machine, which is the VM provided with the CERT BFF (UbuFuzz has ASLR disabled): Every time the above command is executed, the code is located in the same place. From an exploitability perspective, this approach is bad because an attacker can predict the location of code in memory, which enables the use of ROP or return-to-libc style attacks. Let's now enable ASLR by commenting out the kernel.randomize_va_space=0 line in /etc/sysctl.conf. Ubuntu has ASLR enabled by default, but this feature is disabled in the UbuFuzz VM to simplify fuzzing. Once ASLR is re-enabled, we run the test again: Here notice that the stack, heap, and loaded module locations are randomized, but the application itself (cat) is not randomized. Every time it executes, the application is loaded at the same memory location. Grsecurity and Pax As it turns out, it's possible to enable additional exploit mitigations in Linux. Unfortunately, the mitigations are not part of the vanilla Linux kernel. Therefore, you need to get the Linux kernel sources, apply a patch, and build your own kernel. The particular patch in question is provided by grsecurity, which also includes PaX. This patch provides additional protections that help enhance the security of a system, including various memory protections provided by PaX. Compiling and patching your own kernel may sound scary, but it's actually not too difficult. The Insanitybit blog has provided guidance for how to build a grsecurity kernel for Ubuntu. Grsecurity has since been updated to allow an automatic configuration, which makes configuration easier. Let's run the same test on the same UbuFuzz system, but with the grsecurity kernel: The obvious change here is that there is more randomness (higher entropy) in the addresses of the stack, heap, and loaded modules. But notice that cat is still not randomized because cat is not built with PIE, and therefore cannot be randomized on Linux. How do we get application addresses to be randomized on Linux? As mentioned in my previous blog post, for every application we would like to have ASLR protection, we need to compile it with PIE. How practical is this, though? Hardened Gentoo Linux Gentoo Linux is one of the few Linux distributions where packages are compiled from source code, rather than provided in binary format like Red Hat or Ubuntu. Setting up a Gentoo Linux system requires more "wall clock" time due to compilation requirements, and it also requires more human interaction than most other Linux distributions to configure and tweak the system to work smoothly. At least the prevalence of multi-core computer systems these days makes compilation a bit less time consuming than it was in the past. One security benefit of Gentoo is the reduced attack surface of the platform, since you only get what you explicitly ask for. The other aspect that could make a system like Gentoo a little more difficult to attack using a ROP-style attack is the diversity inherent in the platform ecosystem. Depending on which compilation flags a Gentoo administrator believes will make the system faster, the resulting compiled code may be different among Gentoo instances. With any application that may be bruteforced by an attacker, this entropy provided by different compilation flags is not sufficient protection. In our case, though, the particular feature/variant of Gentoo of interest is called Hardened Gentoo. Hardened Gentoo is a Gentoo profile that enables grsecurity and PaX features in the Linux kernel, and configures the toolchain (compiler, linker, etc.) to use security-enhanced features such as PIE. Because the packages are built with the hardened toolchain, packages installed on a Hardened Gentoo system will have extra exploit mitigations. Let's run the same test on a Hardened Gentoo system: Here we can see that everything is randomized, including the executable, and the entropy is higher than a vanilla Linux system. Exploiting a memory corruption vulnerability on such a system would be quite difficult. It is also possible to run Gentoo with a vanilla Linux kernel, but configure the toolchain to enable PIE and other protections. Packages built after this change is made will be compiled with the protections. While a system configured in this way will not be as secure as a system that runs the hardened Linux kernel, this technique may be a compromise for environments where the hardened kernel cannot be used. A Better Example In the above examples, cat provides a simple example that can visualize the effects of ASLR. However, cat really isn't a high-risk application, and due to its trivial nature, we don't expect vulnerabilities to be discovered in it. How can we check the exploit mitigation features of arbitrary programs? The script checksec.sh by Tobias Klein is useful for this purpose. Let's look at the ffmpeg program, which has a large attack surface; we can expect it to contain a number of vulnerabilities. First, on Ubuntu: Any properties that are not green are not the most secure. In this particular case, we can see that ffmpeg on Ubuntu is not compiled with PIE, and therefore will not receive the security benefit of ASLR. This binary also only uses Partial RELRO. Let's look at ffmpeg on a Hardened Gentoo system: In this case, all of the exploit mitigations are present. Conclusion Compared to Windows, enabling extra exploit mitigations on Linux requires a bit more work. Although the tests demonstrated in this blog entry focus on the ASLR aspect, a grsecurity-patched (and therefore PaX-enabled) Linux system provides a large number of protections that can make exploitation more difficult. At least on x86, some of these protections may have a noticeable performance impact. While a Hardened Gentoo platform may enable the most exploit protections for the most parts of the system, this approach may not be for everyone. If you are looking to enhance the security of your Linux system, it may be worth looking into at least building a grsecurity-enabled kernel for the Linux distro that you are already using. Sursa: https://www.cert.org/blogs/certcc/post.cfm?EntryID=193