Nytro

Si, ce crack-uri ati facut?

Se practica si in Romania. Nu treceti cardul prin nicio banda magnetica. Daca sunteti paranoici, puteti zgaria banda magnetica pentru a o deteriora.

Mi se pare interesant si bine de stiut. E un post util. Voi ce faceti util pentru comunitate? @ haterii smecheri.

Si eu am mai multe conturi pe forum.

@haked : https://rstforums.com/forum/search.php?do=finduser&userid=148384&contenttype=vBForum_Post&showposts=1 Niciun post util. Ban 7 zile. Va plangeti toti de Aerosol, dar voi nu faceti nimic pentru comunitate. Verificati-va ultimele posturi inainte de a comenta, sunteti buni doar de trolling dar va plangeti ca forumul a luat-o pe aratura. Din cauza voastra e asa, nu din cauza lui. O sa urmaresc mai atent forumul si la fiecare offtopic: warn, cum faceam in trecut.

Defeating EMET 5.2 Since my last post, i thought if Malware Bytes Anti Exploit can be bypassed in a targetted attack why not work on bypassing EMET using rop chains. But truth be told EMET has tons of good protections which render a lot of methods useless and this form of bypass was only because of my lack of focus/ability to find a combined loophole in all current epxloit mitigations. Idea is, If an exploit author gets to study a system before making his move he/she can defeat the protections. Reading up on articles which claim to bypass EMET before, i came to conclusion that most of the bypasses revolve around the nature of current exploit. If its a flash exploit people can use the already existing bromium suggested stack switching mechanism to thwart stack pivot mitigation. Then do something else to bypass other checks. If its a flash exploit people can use a public sample to jump into a call VirtualProtect ... retn gadget to thwart caller checks of EMET. Then do something to bypass other checks. These checks can be bypassed individually but combined, they are a force to be reckoned with. Although we have seen exploits like 2014-0515 being used to bypass earlier versions of EMET, these exploits come but once in time. TLDR: EMET 5.2 can be bypassed with ease by jumping past its hooks using simple ROP 19th March 2015 Addition: I've bypassed EMET's protections with generic ROP too, no need to specifically target now. However i am not releasing the POC. Only effective bypass up until now for EMET was the one which offensive security guys did. offsec EMET 5.1 While ryujin did some serious roppery, he studied the system. Got the offsets and fucked EMET to its core. I was trying the same approach before, but since the arrival of EMET 5.2 it was only a matter of time before someone reverse engineered EMET's internal structures and found out a bypass. My time was both limited and valuable, So i jumped right into it. Upon watching ollydbg's memory mapping, i saw TONS of page guards in memory. Something told me this approach would only end in sophistication. and i changed my approach thus manually began browsing EMET's hook handler. While what i did cannot be constituted as a disarm, frankly even i dont know what to call it. As long as it gets my exploit in EMET running without any consequences i am good. WinExec routine Hook handler for WinExec Notice the handler routine and 0x26 bytes after that? Yep thats WinExec's replaced bytes. jumping to I found this was generic in my windows 8.1 x64, 7 x64. Frankly speaking i didn't check this in 32bit OS versions, Since EMET didn't work on my xp sp3 VM. Neither did i study how EMET is doing its trampoline. The point is, we can hop these hooks with ease. Not at all difficult. Although i figured the idea, it was not easy to develop a POC from scratch, when I am not a regular developer. I just scrutinize, borrow code chunks and get my way. So i took offensive security's last EMET 5.1 bypass POC and ran it on a base Windows 7 x64 VM. It didn't work because it was built for a different mshtml.dll version than the base which windows 7 comes with. I removed their rop chains and included my own which would work for base windows 7. Exploit used is CVE-2012-1876 developed by sickness. Rop chains as follows Chain of command 1. we find GetModuleHandleW from IAT of mshtml.dll 2. use it to find base address of ntdll 3. add 0x1ffd8 offset for ZwProtectVirtualMemory * 4. inc register by 1 containing address of ZwProtectVirtualMemory 5. get DWORD at ZwProtectVirtualMemory + 1 in a different register 6. add these two registers. (we arrive at hook handler) 7. add 10 twice and increase this address 6 times by 1 8. jump to that while keeping stack proper aligned for its params and return address pointing to nopsled * First things first, i used ZwProtectVirtualMemory because if we try this on VirtualProtect, Its possible we will get burned when it calls ntdll's syscalls while doing a reverse stack walking. Since i didnt had time to check this theory out, i chose for the fastest option and fought for ZwProtectVirtualMemory which is last call from usermode to kernelmode. Since kernel32.VirtualProtect is simply a trampoline to kernelbase.VirtualProtect and msthml doesn't have pointers for kernelbase.dll i couldn't follow that lineup. I chose ntdll. Result, It Works! Now onto a bigger question, Why static offset for ZwProtectVirtualMemory when it will change across different OS versions. 1. you can craft this specific offset (not rop) for different targets for x86 and 64 by querying window.navigator.cpuClass from javascript. it should be undefined for win32 and x86 for win64 2. ZwProtectVirtualMemory is not present in IAT, so i had to get syscall's address somehow. 3. If i use GetProcAddress, HW breakpoint at ntdll will get triggered and for some unknown reason IE stops responding. No logs in EMET. This should work perfectly but wasn't running. Although there are innumerable methods for replacing this hardcoded static offset and achieving reliable exploitation for all different flavours of windows running EMET 5.2. I dont think i have to give one such method in a POC so as to prevent giving out an already weaponized exploit, moreover this exploit is very specific to mshtml version as most exploits with memory leaks do. In essence, as long as we have a reliable rop chain. We can defeat EMET using common gadgets. Now onto the last part, we have made our shellcode RWX, only thing is changing the shellcode to make it work. When i used Ryujin's shellcode for bind shell, it was stopped by stackpivot. I realized, since i simply skipped the hooks, i have to restore stack. so i went ahead and did this __asm { mov esp,fs:[0] sub esp,0x1000 } We also have to bypass EAF because shellcode will trigger that if it contains locating Exports from PEB. so i used my previous EAF bypass Mechanism [here] putting this stackpivot and EAF bypass together, i executed ryujin's shellcode But it didn't work again due to caller checks. Apparently the shellcode was from metasploit and a normal API call in metasploit goes through a handler which will resolve addresses and call the function. So the api call was like this __asm { push 0 push "calc\0" push hash_rol_0xd_WinExec call ebp } and ebp contains the address of a handler which will resolve the api address from hash and jump to it while setting up stack perfectly jupm gadget in this handler is __asm { jmp eax } Now get hold of this, when hook from EMET reads the return address backwards it encounters call ebp. Which is a valid api call according to the caller check. But it also checks if ebp contains the address from where this hook was placed upon. Since ebp contains metasploit api resolution handler, and eax contains WinExec address. Caller check will fail. So i had to craft my own shellcode which would return api address in a register rather than call api by hash. And it worked. POC EMET 5.2 bypass POC Conclusion EMET fights tough, more than any public exploit mitigation solution out there. A lot tougher than MBAE and enterprise exploit detection products. But if we get to study the system, its only a matter of time. Addition: On March 19th 2015, i managed to bypass EMET's protections using GENERIC rop. So even if emet exists or not in the system the exploit works fully. However due to its more negative use than positive, i am not releasing the code. Icing on the top, this bypasses all of the enterprise exploit mitigation toolkits i've got my hands on. Posted by r41p41 at 08:16 Sursa: http://casual-scrutiny.blogspot.in/2015_03_01_archive.html

Pare infectat. Trashed. Descarcati pe riscul vostru: stealer/miner.

Regula generala a forumului: Staff-ul are intotdeauna dreptate.

DYLIB HIJACKING ON OS X Patrick Wardle Synack, USA (This paper was presented at CanSecWest 2015.) DLL hijacking is a well known class of attack which was always believed only to affect the Windows OS. However, this paper will show that OS X is similarly vulnerable to dynamic library hijacks. By abusing various features and undocumented aspects of OS X’s dynamic loader, attackers need only to ‘plant’ specially crafted dynamic libraries to have malicious code automatically loaded into vulnerable applications. Using this method, such attackers can perform a wide range of malicious and subversive actions, including stealthy persistence, load-time process injection, security software circumvention, and a Gatekeeper bypass (affording opportunities for remote infection). Since this attack abuses legitimate functionality of the OS, it is challenging to prevent and unlikely to be patched. However, this paper will present techniques and tools that can uncover vulnerable binaries as well as detect if a hijacking has occurred. Download: https://www.virusbtn.com/pdf/magazine/2015/vb201503-dylib-hijacking.pdf

SAT solving - An alternative to brute force bitcoin mining 03 February 2013Introduction A Bitcoin mining program essentially performs the following (in pseudo-code): while(nonce < MAX): if sha(sha(block+nonce)) < target: return nonce nonce += 1 The task is to find a nonce which, as part of the bitcoin block header, hashes below a certain value.This is a brute force approach to something-like-a preimage attack on SHA-256. The process of mining consists of finding an input to a cryptographic hash function which hashes below or equal to a fixed target value. It is brute force because at every iteration the content to be hashed is slightly changed in the hope to find a valid hash; there's no smart choice in the nonce. The choice is essentially random as this is the best you can do on such hash functions.In this article I propose an alternative mining algorithm which does not perform a brute force search but instead attacks this problem using a number of tools used in the program verification domain to find bugs or prove properties of programs, see as example [9]. Namely, a model checker backed by a SAT solver are used to find the correct nonce or prove the absence of a valid nonce. In contrast to brute force, which actually executes and computes many hashes, my approach is only symbolically executing the hash function with added constraints which are inherent in the bitcoin mining process.The main results besides the recipe for building a SAT-based miner, are: Simple parameter tuning of the used tools leads to over 1000% performance improvement. The proposed algorithm potentially gets more efficient with increasing bitcoin difficulty. This is not the first time SAT solvers are used to analyse a cryptographic hash. Mate Soos et al have done interesting research on extending SAT solvers for cryptographic problems [1]; Iilya Mironov and Lintao Zhang generated hash collisions using off-the-shelf SAT solvers [2]; and many others, e.g. [3, 4]. However, to the best of my knowledge, this is the first description of an application of SAT solving to bitcoin mining.I do not claim that it is a faster approach than brute force, however it is at least theoretically more appealing.To aid understanding, I will introduce some basic ideas behind SAT solving and model checking. Please see the references for a better introduction to SAT solving [11] and bounded model checking [12]. SAT Solving and Model Checking Boolean Satisfiability (SAT) is the problem of finding an assignment to a boolean formula such that the whole formula evaluates to true. As easy as it may sound, it is one of the hard, outstanding problems in computer science to efficiently answer this decision problem. There is a large and thriving community around building algorithms which solve this problem for hard formulas. Actually, each year there is a competition held where the latest, improved algorithms compete against each other on common problems. Thanks to a large number of competitors, a standard input format (DIMACS), and the easy way of benchmarking the performance of SAT solvers there have been massive improvements over the last 10 years. Today, SAT solvers are applied to many problem domains which were unthinkable a few years ago (for example they are used in commercial tools [5, 7] to verify hardware designs).At the core of SAT solvers is a backtracking algorithm with the long name Davis–Putnam–Logemann–Lovelandalgorithm (DPLL) which describes a general way of finding a solution to a propositional formula in CNF format. Wikipedia summarises the algorithm well: The basic backtracking algorithm runs by choosing a literal, assigning a truth value to it, simplifying the formula and then recursively checking if the simplified formula is satisfiable; if this is the case, the original formula is satisfiable; otherwise, the same recursive check is done assuming the opposite truth value. A CNF formula, which is the input to a SAT solver, is made up of literals and clauses. A literal is simply a variable or its negation. A clause is a disjunction of literals. CNF is then any formula which purely consists of conjunctions of clauses.DPLL then consists of a depth-first search of all possible variable assignments by picking an unassigned variable, inferring values of further variables which logically must follow from the current assignment, and resolving potential conflicts in the variable assignments by backtracking.For example, given the formula (¬a?b)?(¬a?c)?(¬b?¬c?d) And a partial solution so far consists of a=true then from the first two clauses we find that b=true and c=true because each clause has to be true; this implies that the last clauses has d=true as well, which yields a satisfiable solution of all variables being true.A common application of SAT solving is (bounded) model checking [12], which involves checking whether a system preserves or violates a given property, such as mutual exclusive access to a specific state in the system. Model checkers such as CBMC [5] directly translate programming languages like C into CNF formulas, in such a way that the semantics of each language construct (such as pointers arithmetic, memory model, etc) are preserved. Clearly, this is quite involved and is done in a number of steps: variables are seen as bitvectors, function calls are expanded, loops are unrolled up to a given depth, the program is transformed into static single assignment form [6], etc.A simple example of the transformation is visible in the following figure from paper [6]: As visible in the figure, the property which should be checked for violations is expressed as an assertion. The bitvector formula C and P above are additionally encoded as C?¬P which is then checked by a SAT solver (after converting it to CNF using the Tseitin transformation). If the formula is satisfiable then there is a variable assignment in the original program which violates the property P (because of the `not`). If it is not possible to make the formula true then the property is guaranteed to hold.Most importantly, in case of satisfiability, the model checker can reconstruct the variable assignment and execution trace (called counterexample) which leads to the violation using the truth variable assignments provided by the solver. Bitcoin mining using SAT Solving and Model Checking Using the above tools we can attack the bitcoin mining problem very differently to brute force. We take an existing C implementation of sha256 from a mining program and strip away everything but the actual hash function and the basic mining procedure of sha(sha(block)). This C file is going to be the input to CBMC. The aim of this is that with the right assumptions and assertions added to the implementation, we direct the SAT solver to find a nonce. Instead of a loop which executes the hash many times and a procedure which checks if we computed a correct hash, we add constraints that when satisfied implicitly have the correct nonce in its solution.The assumptions and assertions can be broken down to the following ideas: The nonce is modelled as a non-deterministic value The known structure of a valid hash, i.e. leading zeros, is encoded as assumptions in the model checker An assertion is added stating that a valid nonce does not exist Let's explain these ideas in more detail. The nonce Instead of a loop that continuously increases the nonce, we declare the nonce as a non-deterministic value. This is a way of abstracting the model. In model checking, non-determinism is used to model external user input or library functions (e.g. a library function returns any possible value); in our case it is a way of moving the search from outside of the actual computation (a brute force loop) to be part of the SAT solver search. The nonce can be seen as the only "free variable" in the model. Encoding the structure Bitcoin mining programs always have to have a function which checks whether the computed hash is below the target (see here for an example). We could do the same and just translate this function straight to CNF, however there is a much better and more declarative solution than that in our case. Instead, we can just assume values which we know are fixed in the output of the hash. This will restrict the search space to discard any execution paths where the assumptions would not be true anymore. Because we are not in a brute force setting, but a constraint solving setting this is very simple to express. We assume the following: Only compute hashes which have N bytes [N depends on the target] of leading zeros.In CBMC this is simple to achieve and looks about as follows: __CPROVER_assume( (state[7] & 0xff) == 0x00 && (state[7]>>8) & 0xff) == 0x00 && ... ); where state is the array containing the resulting hash. It might seem unintuitive to "fix" output variables to certain values, however remember that the code is not executed in a regular fashion but translated as a big formula of constraints. Assumptions on the outputs will result in restrictions of the input -- in our case this means only valid nonces will be considered.This serves three purposes: it encodes the specification of a valid hash, it drives the symbolic execution only along paths which we are actually interested in, and most importantly it cuts down the CNF formula. In this case, the assumptions remove about 100'000 (out of 900k) clauses from the DIMACS file.Again, in comparison, brute force just blindly computes hashes with no way of specifying what we are looking for. The SAT-based solution only computes hashes that comply with the mining specification of a valid hash. The Assertion The most important part is defining the assertion, or the property P as it is called in the section above. The key idea here is that the counterexample produced by the model checker will contain a valid nonce given a clever enough assertion.Why is that? A bounded model checker is primarily a bug finding tool. You specify the invariant of your system, which should always hold, and the model checker will try to find an execution where this invariant is violated (i.e. where there was a satisfiable solution). That is why the P above is negated in the formula.Thus, the invariant, our P, is set to "No valid nonce exists". This is naturally expressed as the assertionassert(hash > target); Which the model checker will encode to its negation as "a valid nonce does exist", i.e. the negation of the above assertion. If a satisfiable solution is found, we will get an execution path to a valid nonce value.In reality, this is encoded more elegantly. Since the leading zeros of a hash are already assumed to be true, all that remains to be asserted is that the value of the first non-zero byte in the valid hash will be below the target at that position. Again, we know the position of the non-zero byte for certain because of the target. For example, if our current target is the following:00 00 00 00 00 00 04FA 620000000000000000000000000000000000000000000000 ^ ^ state[7] state[6] Then the following assertion states that a certain byte in state[6] of the hash has to be above 0x04.if(((state[6] >> 8) & 0xff) > 0x04) { flag = 1; } assert(flag == 1); As the assertion is negated, the SAT solver will be instructed to find a way to make the flag equal to 0. The only way this can be done is by playing with the only free variable in the model -- the nonce. In that way, we just translated the bitcoin mining problem into SAT solving land. Producing a Counterexample Combining the ideas from the above sections results in a conceptual SAT-based bitcoin mining framework. In pseudo C code this looks as follows: void satcoin(unsigned int *block) { // offset into the block header unsigned int *nonce = block+N; // non-deterministically assign a value to the nonce *nonce = nondet_int(); // 'sha' is a standard SHA-256 implementation hash = sha(sha(block)); // assume leading zeros assume(hash[0] == 0x00 && ...); // encode a state where byte M of hash is bigger than target int flag = 0; if(hash[M] > target[M]) flag = 1; // assert there's no hash that is below target assert(flag == 1); } This program is the input to CBMC, which will encode it to CNF and pass it on to a built-in SAT solver, or alternatively output it as DIMACS to use a different solver. The advantage of using the built-in solver is that, in case of satisfiability, the model checker can easily retrieve a counterexample from the solution which consists of all variable assignments in the solution.A violation of the assertion implies a hash below the target is found. Let us inspect a counterexample when run on the genesis block as input. At state 4730 below, the flag was found to be 0 which violates the assertion. Moving upwards in the execution trace we find a valid hash in state 4719. Finally, the value of the non-deterministically chosen nonce is recovered in state 1604.State 1604 file satcoin.c line 108 function verifyhash ---------------------------------------------------- c::verifyhash::$tmp::return_value_nondet_uint$1=497822588 (00011101101011000010101101111100) [.....] State 4719 file satcoin.c line 77 function sha_processchunk ---------------------------------------------------- verifyhash::1::state={ 1877117962, 3069293426, 3248923206, 2925786959, 2468250469, 3780774044, 1758861568, 0 } [.....] State 4730 file satcoin.c line 153 function verifyhash ---------------------------------------------------- verifyhash::1::flag=0 (00000000000000000000000000000000) Violated property: file satcoin.c line 160 function verifyhash assertion flag == 1 VERIFICATION FAILED Two lines of python verify that the hash is correct (when compared with the genesis block):>>> ints = [1877117962, 3069293426, 3248923206, 2925786959, 2468250469, 3780774044, 1758861568, 0] >>> struct.pack('>8I', *ints).encode('hex_codec') '6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000' Evaluation The implementation of the above program generates a large CNF formula with about 250'000 variables and 850'000 clauses. In order to evaluate its performance I generated two benchmark files where one has a satisfiable solution and the other does not. I restricted the nonce range (the possible values to be chosen) to 1000 values for each file. The files are available on the following github project.Current state of the art SAT solvers, most having won one or multiple competitions, are tested on the filesout_1k_sat.cnf and out_1k_unsat.cnf. Unsurprisingly, the solvers are not capable of solving this problem efficiently as of now. However, it is interesting to see the differences in runtime.First the table for out_1k_unsat.cnf. [TABLE=width: 480] [TR] [TH]SAT Solver[/TH] [TH]Time to UNSAT[/TH] [/TR] [TR] [TD]Cryptominisat 2.9.2[/TD] [TD]49s[/TD] [/TR] [TR] [TD]Cbmc 4.0 Minisat[/TD] [TD]1m18s[/TD] [/TR] [TR] [TD]Rsat 2.01[/TD] [TD]2m08s[/TD] [/TR] [TR] [TD]restartsat[/TD] [TD]1m35s[/TD] [/TR] [TR] [TD]Minisat 2.0[/TD] [TD]2m09s[/TD] [/TR] [TR] [TD]ManySat 2.0[/TD] [TD]2m24s[/TD] [/TR] [TR] [TD]Precosat 576[/TD] [TD]2m30s[/TD] [/TR] [TR] [TD]Glucose 2.1[/TD] [TD]2m35s[/TD] [/TR] [TR] [TD]ZChaff 2004.11.15[/TD] [TD]4m10s[/TD] [/TR] [TR] [TD]Lingeling ala[/TD] [TD]Did not terminate (40m+)[/TD] [/TR] [/TABLE] Cryptominisat wins the UNSAT challenge by being faster than all the other solvers. This is interesting as Cryptominisat has been specifically tuned towards cryptographic problems as it is able to detect and treat xor clauses differently to normal clauses [1]. This feature is extensively used in this case, in the above run the solver found over 95000 non-binary xor clauses.In UNSAT, every solver has to perform the same amount of basic work of trying out 1000 nonce values. The crypto-focused optimisations of Cryptominisat could potentially have helped in solving this more efficiently than the other solvers.Next, the results for out_1k_sat.cnf. [TABLE=width: 480] [TR] [TH]SAT Solver[/TH] [TH]Time to SAT[/TH] [/TR] [TR] [TD]Cryptominisat 2.9.2[/TD] [TD]42s[/TD] [/TR] [TR] [TD]Cbmc 4.0 Minisat[/TD] [TD]1m05s[/TD] [/TR] [TR] [TD]Rsat 2.01[/TD] [TD]1m29s[/TD] [/TR] [TR] [TD]restartsat[/TD] [TD]38s[/TD] [/TR] [TR] [TD]Minisat 2.0[/TD] [TD]1m70s[/TD] [/TR] [TR] [TD]ManySat 2.0[/TD] [TD]1m16s[/TD] [/TR] [TR] [TD]Precosat 576[/TD] [TD]1m23s[/TD] [/TR] [TR] [TD]Glucose 2.1[/TD] [TD]45s[/TD] [/TR] [TR] [TD]ZChaff 2004.11.15[/TD] [TD]22s[/TD] [/TR] [TR] [TD]Lingeling ala[/TD] [TD]Did not terminate[/TD] [/TR] [/TABLE] First, it is unsurprising that the SAT timings are generally lower than UNSAT as the solvers do not have to try all possible nonce values. However, it is very surprising that ZChaff wins the SAT challenge with a good margin to the next solver. ZChaff is the oldest of all solvers presented here, the version I am using is 9 years old. This could indicate that the heuristics applied by modern SAT solvers do not help in this particular instance.Generally, it is not known what makes a SAT instance hard or easy, which leaves only speculation or analysis of the stats provided by the SAT solvers to come to useful conclusions. I could speculate that the avalanche effect of the hash function produces a very structured CNF formula with high dependencies between clauses and variables. Perhaps a higher degree of randomisation applied by heuristics performs less well than straight-forward DPLL. I leave this to someone with more SAT solving knowledge to decide.Let's try to improve these numbers a bit with some parameter tuning. Tuning and Improvements While the performance numbers are not great (compared to GPU mining) we have to keep in mind that this is entirely unoptimised and there are many ways of how this can be sped up. To give an idea of the performance gains that can be achieved with little effort I am going to use a combination of features: Firstly, the model checker allows slicing the algorithm at the program level (before translating it to CNF). Here, anything that is unrelated to the assertion will be sliced away. As the code for the miner is relatively small and none of the SHA-256 code paths are unused, this only slims down the CNF formula by 500 clauses, however it still does have an effect at times. Secondly, SAT solvers usually have a large number of parameters to play with like the frequency to pick a random branching choice as decision heuristic. In this experiment, I am going to use Cryptominisat as it performed well in the UNSAT challenge and has a large number of parameters with parameter tuning and slicing. [TABLE=width: 480] [TR] [TH]File[/TH] [TH]Nonce Range[/TH] [TH]Timing[/TH] [TH]Speedup[/TH] [TH]Parameters[/TH] [/TR] [TR] [TD]out_1k_sat.cnf[/TD] [TD]1000[/TD] [TD]8s[/TD] [TD]525%[/TD] [TD]noconglomerate, restrict=32[/TD] [/TR] [TR] [/TR] [TR] [TD]out_1k_sat.cnf[/TD] [TD]1000[/TD] [TD]4s[/TD] [TD]1050%[/TD] [TD]plain, restrict=32[/TD] [/TR] [TR] [TD]out_10k_sat_sliced.cnf[/TD] [TD]10'000[/TD] [TD]36s[/TD] [TD]600% (original 3m39s)[/TD] [TD]noconglomerate, restrict=4500[/TD] [/TR] [/TABLE] Simply adding two parameters to Cryptominisat already improves the performance by over 500%. The restrict parameter is a way to only branch on the 32 most active variables which is intended for cryptography key search -- 32 was picked arbitrarily. In the second row, I tried running it with the plain parameter which deactivates all simplification heuristics, in order to see if the speculations around the ZChaff-speed improvement could also apply to Cryptominisat. Indeed, a 1000% improvement clearly shows that a simpler solver performs better on this instance.For the last row, I increased the nonce range to 10'000 values which leads to an interesting result. The unoptimised run of this file is only 3m39s; this is half the expected time when we take the 42s benchmark on 1000 nonces and assume that the search time increases linearly with the nonce range. This does not seem to be the case. Apart from that observation, a 600% improvement is achieved with naive parameter tuning.Apart from parameter tuning there's quite a few things that should have an even larger impact on performance. Here are a couple of examples: It is not using the midstate. This should be the most obvious way of improving performance. With the midstate precomputed, it will make one less hash call, which dramatically reduces the size of the formula (remember there are no function calls but everything is inlined). As demonstrated, tailored SAT solvers perform better than more off-the-shelf ones. Tuning the SAT solver combined with encoding the problem better (see next point) is definitely the way to get better performance. Most solvers have a large number of parameters to tweak. Additionally, parallel, GPU and FPGA based solvers do exist [8]. Encoding the problem to CNF can be done much more efficiently and directly than what can be achieved with a general purpose model checker such as CBMC. For example, the authors of this paper [10] developed their own toolkit to translate hash functions to CNF. Perhaps most interestingly, additional constraints and assumptions could be found which would potentially speed up the search even further. Bitcoin Difficulty and Assumptions A very intriguing, and perhaps unintuitive property of the algorithm proposed is that with increasing bitcoin difficulty, or equally lower target, the search could become more efficient, at least in theory. This is because we can assume more about the structure of a valid hash -- a lower target means more leading zeros which are assumed to be zero in the SAT-based algorithm.If this is true and is a substantial effect then this is an important issue since the rate of the money supply is regulated with the difficulty. The higher the difficulty, the less likely it is that an individual block has a valid nonce. However, conventional mining algorithms always have to perform the same amount of work (i.e. try 4 billion nonce values) to reject a block. On the other hand, "Satcoin" miners will get progressively faster which could lead to imbalances in the controlled supply. These are all just speculations and depend on many factors, first and foremost how well the SAT-based approach can be improved and whether the probability of finding a valid nonce does not dwarf the efficiency gain of the algorithm.To explore this hypothesis, I also ran the algorithm on block 218430 that was found at the end of January 2013. Since it is obviously a block later in the history than the genesis block (block 0) its target is smaller. The target of the genesis block is the following:00000000ffff0000000000000000000000000000000000000000000000000000 The one of block 218430 is clearly lower and shows more leading zeros which means more of the hash output will be 'fixed' (assumed to be zero) in advance:00000000000005a6b10000000000000000000000000000000000000000000000 The next table again shows the runtimes to SAT for 1000 nonces on block 218430. The last column shows the speedup against block 0. [TABLE=width: 480] [TR] [TH]SAT Solver[/TH] [TH]Time to SAT[/TH] [TH]Speedup[/TH] [/TR] [TR] [TD]Cryptominisat 2.9.2[/TD] [TD]54s[/TD] [TD]-10%[/TD] [/TR] [TR] [TD]Cbmc 4.0 Minisat[/TD] [TD]1m11s[/TD] [TD]-9%[/TD] [/TR] [TR] [TD]Rsat 2.01[/TD] [TD]1m10s[/TD] [TD]+27%[/TD] [/TR] [TR] [TD]restartsat[/TD] [TD]26s[/TD] [TD]+42%[/TD] [/TR] [TR] [TD]Minisat 2.0[/TD] [TD]Did not terminate[/TD] [TD][/TD] [/TR] [TR] [TD]ManySat 2.0[/TD] [TD]39s[/TD] [TD]+94%[/TD] [/TR] [TR] [TD]Precosat 576[/TD] [TD]25s[/TD] [TD]+232%[/TD] [/TR] [TR] [TD]Glucose 2.1[/TD] [TD]1m17s[/TD] [TD]-42%[/TD] [/TR] [TR] [TD]ZChaff 2004.11.15[/TD] [TD]Did not terminate[/TD] [TD][/TD] [/TR] [TR] [TD]Lingeling ala[/TD] [TD]Did not terminate[/TD] [TD][/TD] [/TR] [/TABLE] Initially, two more solvers, Minisat and ZChaff, did not terminate within the specified timeout (40 minutes). Apart from that, we see a number of good speed ups compared to the Block 0 timings. Generally, it is hard to benchmark SAT solvers (see [13]) since comparing different heuristics of different solvers can lead to inconsistent results. The paper [13] on benchmarking SAT solver suggests dropping all timeouts and using the geometric mean (in a slightly different context) to evaluate runtimes and speedups. The geometric mean runtime for block 0 over all solvers is 59s, while block 218430 clocks in at 47s, which is indeed faster.Lastly, let us apply the ZChaff-speed up lesson from the previous section and run the same file with Cryptominisat and the parameters "plain, restrict=32". The result is 2.5s until a solution is found which is 2160% faster than without tuning and another 160% speedup to the best time of block 0 in the previous section. Looking at the solver statistics shows less restarts (5 instead of 6), less conflicts (858 vs 158), and less conflict literals (4785 vs 12686) compared to block 0 which could indeed hint towards higher algorithmic efficiency with growing bitcoin difficulty. Conclusion I introduced a novel algorithm to solve the bitcoin mining problem without using (explicit) brute force. Instead, the nonce search is encoded as a decision problem and solved by a SAT solver in such a way that a satisfiable instance contains a valid nonce. The key ingredients in the algorithm are a non-deterministic nonce and the ability to take advantage of the known structure of a valid hash using assume statements.A couple of benchmarks demonstrated that already with simple parameter tuning dramatic speed ups can be achieved. Additionally, I explored the contentious claim that the algorithm might get more efficient with increasing bitcoin difficulty. Initial tests showed that block 218430 with considerably higher difficulty is solved more efficiently than the genesis block 0 for a given nonce range. References [1] Mate Soos, Karsten Nohl, and Claude Castelluccia: Extending SAT Solvers to Cryptographic Problems. SAT 2009. pdf [2] Ilya Mironov and Lintao Zhang: Applications of SAT Solvers to Cryptanalysis of Hash Functions. SAT 2006. pdf [3] Fabio Massacci: Using Walk-SAT and Rel-SAT for cryptographic key search. IJCAI 1999. pdf [4] Benjamin Bloom: SAT Solver Attacks on CubeHash. Thesis 2010. pdf [5] http://www.cprover.org/cbmc/ [6] Edmund Clarke, Daniel Kroening, and Flavio Lerda: A tool for checking ANSI-C programs. TACAS 2004. pdf [7] Ben Chelf and Andy Chou: The next generation of static analysis. White paper. pdf [8] Leopold Haller and Satnam Singh: Relieving Capacity Limits on FPGA-Based SAT-Solvers. pdf [9] Jonathan Heusser and Pasquale Malacaria: Quantifying information leaks in software. ACSAC 2010. acm pdf [10] Pawel Morawiecki and Marian Srebrny: A SAT-based preimage analysis of reduced KECCAK hash functions. 2010. pdf [11] Koen Claessen, Niklas Een, Mary Sheeran, and Niklas Sorensson: SAT-solving in practice. 2012. pdf [12] Edmund Clarke, Armin Biere, Richard Raimi, and Yunshan Zhu: Bounded Model Checking Using Satis?ability Solving. Form. Methods Syst. Des. 2001. pdf [13] Emmanuel Zarpas: Benchmarking SAT Solvers for Bounded Model Checking. SAT 2005. pdf Sursa: http://jheusser.github.io/2013/02/03/satcoin.html

UEFI Programming - First Steps [TABLE=class: metainfo noborder, width: 980] [TR] [TD]vid, 2009-03-31[/TD] [TD=align: right]Revision: 1.0[/TD] [/TR] [/TABLE] In this article, I will describe steps needed to start on with development of real UEFI applications on x86 PC, and share some practical experiences with problems doing so. I will focus on 64-bit version of UEFI, because the 32-bit version isn't much used in this area (most likely due to Microsoft decision not to support UEFI in 32-bit Vista). So, to follow some of my steps here, you'll need a 64-bit CPU (but not 64-bit OS, you can use any 32-bit OS as well). We will finish this article with EFI Hello World application. This article is continuation of my previous article Introduction to UEFI. Make sure to understand things described there, before reading on. Of course, anything you try according to this article, you are doing at your own risk. Getting the hardware To start UEFI development, first of all you need to get a motherboard whose BIOS has UEFI support. (more precisely we should probably say "whose firmware has UEFI support", but I will use this form). Finding whether particular BIOS has UEFI support often turns out to be quite complicated task. Motherboard manufacturers license BIOS from other companies, usually from AMI (Aptio, AMIBIOS), Phoenix (SecureCore, TrustedCore, AwardCore) or Insyde (InsydeH20). Forget about determining UEFI support just by end-user stats you see in most shops. Since UEFI support is still only in somewhat experimental state, in many cases it isn't even listed in motherboard technical specification. In such case you are left to googling and asking on forums, where you often get only internal brand name that is often hard to match with end-user product designation. One trick that I found out to work for Intel boards (but it may very well work for other boards as well) is to look at BIOS Update Release Notes, e. g. the document which lists changes and fixes of BIOS. If board has UEFI support, you will probably find UEFI mentioned there (and only there in case of Intel). In short, determining UEFI support is much harder than it may seem. Some machines that have this technology are listed here. I use Intel DG33BU board (it was marketed as Intel DG33BUC for some reason). You will also need some place to boot from. In theory just USB pen should be enough, but in practice none of 4 brands I tried worked with my board's UEFI implementation. So you may have to use harddrive. I strongly suggest IDE drive, because SATA drives may need some tweaking of BIOS settings, or they may not work at all. Like the USB pens, USB keyboard might be a problem too. I wouldn't fear this that much, but if you can use PS/2 keyboard, do so. Getting the software To go on with UEFI development, you will need two development packages: EFI Development Kit (EDK) and EFI Toolkit. First package, the EFI Development Kit contains the TianoCore (public part of reference UEFI implementation by Intel) source code, along with many examples and binaries of EFI Shell (we'll talk about this later), all ready to be built with nice make system. It even can be built into a Win32 UEFI emulator for more convinient development and testing, but I won't cover that here. I also won't demonstrate usage of EDK build system in this article. Even though it might be a good idea for real world project, I want to give you bit more insight about what goes "under the hood" here. Second package, the EFI Toolkit is set of extra UEFI applications like FTP client, Python port, text editor, etc. Strictly speaking, we don't really need this, but it has a set of C headers that is somewhat easier to use than those of EDK (unless you take advantage of EDK build system for your project). However, note that it doesn't contain all headers yet - you will quickly run into this problem if you try some real development with it. Along with headers, you also will need documentation of the UEFI interface. That can be downloaded after filling simple form atUnified Extensible Firmware Interface Forum. This is the official UEFI specification. Except for UEFI specification, there is also another document called Platform Initialization Specification. This describes implementation of UEFI initialization stages (before drivers are loaded and applications can be executed), and more importantly for us, it also describes interface of routines used to implement UEFI. We can understand this Platform Initialization Specification as description of Tiano UEFI implementation. It provides more lowlevel control than UEFI, in cases when such control is needed. Strictly speaking, someone may implement UEFI Specification without implementing anything from Platform Initialization Specification, but that's not very likely to happen in real world. Last but not least, you will need 64-bit C compiler. I suggest Microsoft Visual C++, whose 64-bit version is freely available in Windows DDK. You can get ithere. Booting into EFI Shell Up to this point, you may have lacked any visual idea about UEFI. It was just a programatic interface, after all. Purpose of this chapter would be to overcome this, by booting the so-called EFI Shell. EFI shell is much like any other shell you know: you have a command line, through which you can enter commands to browse disk, run applications, configure system, etc. Only difference is that EFI shell is only built using UEFI services, and as such it doesn't require any operating system to run. Working in EFI shell feels much like working in some very simple operating system. From this shell you will also run your applications (later in this article). Actual steps of booting EFI shell might vary a lot among different BIOS brands. Some BIOSes (mostly on MACs where EFI is the primary standard) have extra options for specifying file to boot, or can even have EFI shell built-in inside ROM. However, I only have experience with non-MAC Intel UEFI implementation, that only seems to support the very minimum of features required to install EFI versions of Windows. Microsoft requirements on UEFI implementation, among other things, specify that UEFI boot loader must use fixed path to file to boot, and if it can't boot UEFI for some reason, it must silently switch to default boot. That causes lot of headache when your UEFI doesn't boot as it should, and you must find out what the problem is without any information from loader. For 64-bit UEFI implementations, the path to file that is booted is \EFI\BOOT\BOOTX64.EFI. UEFI boot loader searches all filesystems it can access for this file, and when it finds it, it is executed. As I already said, if the file isn't found, booting continues with legacy BIOS. UEFI boot loader can read MBR or GPT partition tables, and can only read FAT32 partitions. This includes USB drives, so it is possible to boot EFI shell from FAT32-formatted USB pen. Unfortunately, in my tests 3 of 4 USB pens didn't work, and the 4th stopped working too after BIOS update. I had similar problem with one of two SATA drives not working with UEFI. Therefore, I strongly suggest to use IDE drive, if you have any problems. If you already have at least one FAT32 partition on your drive, you can use it, otherwise you need to create fresh new one. Now you need to copy binary of EFI shell to that partition. You can find 64-bit binary of EFI shell in EFI Development Kit: {EDK}\Other\Maintained\Application\UefiShell\bin\x64\Shell_full.efi. Copy it to your FAT32 partition as \EFI\BOOT\BOOTX64.EFI. Now reboot, and enter into BIOS settings. In the Boot tab, you should see an UEFI Boot option, enable it. If everything is allright (likely not), now after reboot you should end up in the EFI Shell. If you did, congratulations. If you didn't, and instead your regular OS booted as usual, it most likely means that UEFI boot manager wasn't able to access the drive. First try to enter Boot Menu during BIOS screen (F10 on my machine). If the EFI Shell on FAT32 partition was detected, but didn't boot, you will see it as one of option (in my case [internal EFI Shell--Harddrive]). If you see it, just run it. This might possibly happen if you already have some EFI operating system installed, and it has written itself as default EFI boot entry to NVRAM. If you don't see EFI Shell in the Boot Menu, it means UEFI Boot Loader wasn't able to find any FAT32 drive with \EFI\BOOT\BOOTX64.EFI. If you are trying to boot EFI shell from USB key, try tweaking USB emulation settings in BIOS. Same applies to SATA disks and SATA/IDE settings. If none of settings work, or your machine failed to boot from IDE drive, I can't help you any more than to doublecheck everything I wrote so far (especially typos in path to EFI shell). If you have some experience with booting EFI shell not covered in this chapter, please drop me a message, so I can update this article. Building an UEFI application So, we are in EFI shell. That means we can finally test any (64-bit) EFI application we write. Time to start writing one. We will of course write and compile applications in normal operating system, not in EFI shell. EFI application or driver is just a plain Windows PE DLL file, just with different subsystem value in header. There are 3 new values: EFI application = 10, EFI boot service driver = 11, efi runtime driver = 12 (numbers are decimal). Question how to set subsystem will be answered later, for now let's focus on the DLL file. EFI PE application doesn't have any fancies we have in Windows PEs, like symbol tables, exports, static exception handling data, etc. It does not even have imports - all you will ever need in EFI application is passed as argument to entry point function. Only thing needed apart from data and code are relocations. So, this is simplest EFI application: #include <efi.h> EFI_STATUS main(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) { return EFI_SUCCESS; } Compiling it with MS Visual C (supply your own path to EFI toolkit): cl /c /Zl /I"{EFI_Toolkit}\include\efi" /I"{EFI_Toolkit}\include\efi\em64t" hello.c Here we set path to common EFI headers, and to platform-specific EFI headers. The /c switch disables linking (we will link separately for better readability), and /Zl disables dependency on default libc libraries. Linking: link /entry:main /dll /IGNORE:4086 hello.objThe /entry:main overrides default libc entry point to our main() function. The /dll forces creation of relocations. And the IGNORE:4086 disables warningLNK4086, that is caused by nonstandard main() arguments. Now we have windows DLL, we just need to change PE subsystem value to EFI. For that, EFI Toolkit contains simple (buggy) utility that changes subsystem to one of 3 EFI values. We find this utility in EFI_Toolkit\build\tools\bin\fwimage.exe. To set subsystem to EFI app, we'll use it like this: fwimage app hello.dll hello.efiProduced file hello.efi should now be functional empty EFI application. We just need to copy it to our FAT32 partition, reboot to EFI shell, and test it: Shell> fs0: fs0:> .\hello.efiIf we don't get any error message, application worked. UEFI Programming Now we finally can get deeper into UEFI programming. Your main source for this information should be the UEFI specification, I will only sum up most basic points. First of all, we should know something about environemnt of UEFI applications. I will describe only environment of 64-bit x86 UEFI here (other to be found in UEFI specification). UEFI runs in uniprocessor flat 64-bit long mode. Usually UEFI runs with memory mapping disabled (physical RAM address = virtual RAM address), but since 64-bit x86 mode requires mapping to be enabled, UEFI maps entire memory so that virtual address is same as physical (i. e. mapping is transparent). Calling convention is usual 64-bit fastcall (first 4 arguments in RCX, RDX, R8, R9 with space reserved on stack; rest of arguments passed by stack; RAX, R10, R11 and XMM0-XMM5 not preserved by called function), so you don't need to worry about special compiler settings. Notable feature of EFI is that for every supported architecture, it defines exact binary interface (ABI). Now let's look at how our application interacts with UEFI services. First, UEFI provides set of services, called Boot Services. These are available to EFI drivers, applications, and to OS boot loader during boot. At some point during OS booting, OS loader can decide to drop them, and after that point those services become unavailable. There is also a little number of services that always remain available, called "Runtime Services". Apart from these two sets of services, all that UEFI offers is available through so-called protocols. Protocol is very much like a class in object oriented programming. UEFI defines set of protocols itself (for example protocols handling USB, filesystem, compression, network, …), and application can define its own protocols (hence the "Extensible" in "Unified Extensible Firmware Interface"). Protocols are identified by GUID (Global Unique Identifier, google it if you don't know what it is). Only very few protocols are mandatory in UEFI specification, and all the rest may or may not be implemented in particular firmware. If protocol isn't implemented in firmware, you can load a driver that implements it, or even write such driver yourself. Now let's look at how to access these services. As I already explained, all you ever need is passed as argument to entry point function. Prototype of entry point function looks like this: EFI_STATUS main( EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable ) First argument is handle of our process, nothing extra to say about it. Second is pointer to EFI_SYSTEM_TABLE, the top-level EFI structure, which keeps references to everything there is: boot/runtime services, drivers, protocol implementations, memory maps, etc. It is good idea to always save both these arguments in a global variable, so you can access them from anywhere in source code. You can find detailed description of EFI System Table in UEFI Specification chapter 4 - EFI System Table. Its C definition looks like this: typedef struct _EFI_SYSTEM_TABLE { EFI_TABLE_HEADER Hdr; CHAR16 *FirmwareVendor; UINT32 FirmwareRevision; EFI_HANDLE ConsoleInHandle; SIMPLE_INPUT_PROTOCOL *ConIn; EFI_HANDLE ConsoleOutHandle; SIMPLE_TEXT_OUTPUT_PROTOCOL *ConOut; EFI_HANDLE StandardErrorHandle; SIMPLE_TEXT_OUTPUT_PROTOCOL *StdErr; EFI_RUNTIME_SERVICES *RuntimeServices; EFI_BOOT_SERVICES *BootServices; UINTN NumberOfTableEntries; EFI_CONFIGURATION_TABLE *ConfigurationTable; } EFI_SYSTEM_TABLE; Here we see references to boot and runtime services, three standard I/O handles (as implementations of SIMPLE_TEXT_OUTPUT and SIMPLE_INPUT protocols), and pointer to Configuration Table. Configuration Table holds references to all other protocol implementations currently active in system. First we will show example of using Boot Service. The EFI_BOOT_SERVICES is just a structure that holds pointers to functions described in UEFI Specification chapter 6: Services - Boot Services. For now we will use only simple Exit() function, that terminates current EFI application immediately. #include <efi.h> EFI_STATUS main(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) { SystemTable->BootServices->Exit(); // we never get here return EFI_SUCCESS; } Now, we will show simple Hello World application, using the ConOut implementation of SIMPLE_TEXT_OUTPUT protocol. This protocol is described in UEFI Specification chapter 11.4 - Simple Text Output Protocol. Its C header looks like this: typedef struct _EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL { EFI_TEXT_RESET Reset; EFI_TEXT_STRING OutputString; EFI_TEXT_TEST_STRING TestString; EFI_TEXT_QUERY_MODE QueryMode; EFI_TEXT_SET_MODE SetMode; EFI_TEXT_SET_ATTRIBUTE SetAttribute; EFI_TEXT_CLEAR_SCREEN ClearScreen; EFI_TEXT_SET_CURSOR_POSITION SetCursorPosition; EFI_TEXT_ENABLE_CURSOR EnableCursor; SIMPLE_TEXT_OUTPUT_MODE *Mode; } EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL; [FONT=verdana]We are of course interested in OutputString() function, whose prototype is:[/FONT] EFI_STATUS OutputString ( IN EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL *This, IN CHAR16 *String ); Note that UEFI uses Unicode strings only, hence the CHAR16 *String. This pointer meaning is exactly same as in any object oriented programming. With this info, we should be able to write Hello World app easily: #include <efi.h> EFI_STATUS main(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable) { SystemTable->ConOut->OutputString(SystemTable->ConOut, L"Hello World\r\n"); return EFI_SUCCESS; } Also note that UEFI uses CRLF line terminators (\r\n) instead of just LF (\n), and when we use native EFI functions, there is no layer which reinterprets LF to CRLF. Normally, applications use additional library called EFILIB which does the LF->CRLF transform. UEFI Programming with FASM As an extra, I will also demonstrate same Hello World example in assembly (using FASM, that currently has experimental UEFI support since version 1.67.28): First we need some to create simple UEFI headers (efi.inc): ;for 32/64 portability and automatic natural align in structure definitions struc int8 { . db ? } struc int16 { align 2 . dw ? } struc int32 { align 4 . dd ? } struc int64 { align 8 . dq ? } struc intn { align 8 . dq ? } struc dptr { align 8 . dq ? } ;symbols EFIERR = 0x8000000000000000 EFI_SUCCESS = 0 EFI_LOAD_ERROR = EFIERR or 1 EFI_INVALID_PARAMETER = EFIERR or 2 EFI_UNSUPPORTED = EFIERR or 3 EFI_BAD_BUFFER_SIZE = EFIERR or 4 EFI_BUFFER_TOO_SMALL = EFIERR or 5 EFI_NOT_READY = EFIERR or 6 EFI_DEVICE_ERROR = EFIERR or 7 EFI_WRITE_PROTECTED = EFIERR or 8 EFI_OUT_OF_RESOURCES = EFIERR or 9 EFI_VOLUME_CORRUPTED = EFIERR or 10 EFI_VOLUME_FULL = EFIERR or 11 EFI_NO_MEDIA = EFIERR or 12 EFI_MEDIA_CHANGED = EFIERR or 13 EFI_NOT_FOUND = EFIERR or 14 EFI_ACCESS_DENIED = EFIERR or 15 EFI_NO_RESPONSE = EFIERR or 16 EFI_NO_MAPPING = EFIERR or 17 EFI_TIMEOUT = EFIERR or 18 EFI_NOT_STARTED = EFIERR or 19 EFI_ALREADY_STARTED = EFIERR or 20 EFI_ABORTED = EFIERR or 21 EFI_ICMP_ERROR = EFIERR or 22 EFI_TFTP_ERROR = EFIERR or 23 EFI_PROTOCOL_ERROR = EFIERR or 24 ;helper macro for definition of relative structure member offsets macro struct name { virtual at 0 name name end virtual } ;structures struc EFI_TABLE_HEADER { .Signature int64 .Revision int32 .HeaderSize int32 .CRC32 int32 .Reserved int32 } struct EFI_TABLE_HEADER struc EFI_SYSTEM_TABLE { .Hdr EFI_TABLE_HEADER .FirmwareVendor dptr .FirmwareRevision int32 .ConsoleInHandle dptr .ConIn dptr .ConsoleOutHandle dptr .ConOut dptr .StandardErrorHandle dptr .StdErr dptr .RuntimeServices dptr .BootServices dptr .NumberOfTableEntries intn .ConfigurationTable dptr } struct EFI_SYSTEM_TABLE struc SIMPLE_TEXT_OUTPUT_INTERFACE { .Reset dptr .OutputString dptr .TestString dptr .QueryMode dptr .SetMode dptr .SetAttribute dptr .ClearScreen dptr .SetCursorPosition dptr .EnableCursor dptr .Mode dptr } struct SIMPLE_TEXT_OUTPUT_INTERFACE[FONT=verdana]And here is the assembly code itself ([URL="http://x86asm.net/articles/uefi-programming-first-steps/hello.asm"]hello.asm[/URL]):[/FONT] format pe64 dll efi entry main section '.text' code executable readable include 'efi.inc' main: sub rsp, 4*8 ; reserve space for 4 arguments mov [Handle], rcx ; ImageHandle mov [SystemTable], rdx ; pointer to SystemTable lea rdx, [_hello] mov rcx, [SystemTable] mov rcx, [rcx + EFI_SYSTEM_TABLE.ConOut] call [rcx + SIMPLE_TEXT_OUTPUT_INTERFACE.OutputString] add rsp, 4*8 mov eax, EFI_SUCCESS retn section '.data' data readable writeable Handle dq ? SystemTable dq ? _hello du 'Hello World',13,10,'(From EFI app written in FASM)',13,10,0 section '.reloc' fixups data discardableCompile and link it with fasm.exe hello_world.asm. That's all for now, hope you enjoyed yourselves. Sursa: http://x86asm.net/articles/uefi-programming-first-steps/

Taming the wild copy: Parallel Thread Corruption Posted by Chris Evans, Winner of the occasional race Back in 2002, a very interesting vulnerability was found and fixed in the Apache web server. Relating to a bug in chunked encoding handing, the vulnerability caused a memcpy() call with a negative length with the destination on the stack. Of course, many parties were quick to proclaim the vulnerability unexploitable beyond a denial of service. After all, a negative length to memcpy() represents a huge copy which is surely guaranteed to hit an unmapped page and terminate the process. So it was a surprise when a working remote code execution exploit turned up for FreeBSD and other BSD variants, due to a quirk in their memcpy() implementations! This GIAC paper archives both the exploit as well as an analysis (appendix D) of how it works. For the purposes of this post, we define “wild copy” as a copy where both: The attacker has limited control over the length of the copy. The copy will always end up being so large as to be guaranteed to hit an unmapped page. There have been plenty of other interesting cases where a wild copy has ended up being exploitable: A general attack against corruption of structured exception handlers (SEH) on Windows. The BSD variants don’t have a monopoly on memcpy() quirks. In 2011, there was a fascinating outright eglibc vulnerability in Ubuntu, triggering for any very large length to memcpy(). A memset() variant was exposed via the Chromium Vulnerability Rewards Program. The Java Runtime Environment has a very complicated crash handler installed, which is called when a wild copy inevitably causes an access violation. If the crash handler is not careful to be robust in the presence of arbitrarily corrupted heap state, it might crash itself in a more controlled and exploitable way. All of the above cases have one thing in common: the wild copy becomes exploitable due to a secondary issue or quirk. Is it possible to exploit a wild copy without relying on a secondary issue? This is an interesting question for Project Zero to tackle -- when we explore exploitation, we usually only do so for cases where we think we can learn new insights or advance the public state of the art. Today, we’re going to explore a wild copy exploit in the Flash plug-in for 64-bit Chrome Linux. It’s time to introduce issue 122 and “parallel thread corruption”. Issue 122 is an Adobe Flash vulnerability that was fixed back in November 2014. It’s a curious bug wherein the G711 sound codec is straight up broken on some platforms, always resulting in a wild copy when the codec tries to decode some samples. When triggered, it causes a memmove() on the heap with a small negative value as the length parameter. On modern Linux, the memmove() implementation appears to be solid, and the inexorable SIGSEGV appears to take the process down cleanly. We have our work cut out! Step 1: choose an approach We’re going to attempt a “parallel thread corruption”, which is where we observe and abuse the side effects in thread A of an asynchronous memory corruption in thread B. Since thread B’s corruption will always end in a crash, we need to run both threads in parallel. We also need to win a tricky race condition: get code execution before thread B’s crash takes out thread A. As is common in Flash exploits, we’re going to attempt to have our memory corruption corrupt the header of a Vector.<uint> buffer object, expanding its length beyond reality thus leading to the ability to read and write out of bounds. Vector.<uint> buffer objects have their data allocated inline after the header, and in the case of this specific vulnerability, the errant memmove() always ends up shifting memory content backwards by 2048 bytes. So if we allocate a large enough Vector.<uint>, we can attempt to corrupt its header with its own data: | len: 2000 | some ptr | data[0] = 0, data[1] = 0, …, data[508] = 0xfee1dead, … | ^ | |----------------------------------------------------------- The offsets and alignments work out such that the 508th 4-byte uint data element will clobber the length in the header. Step 2: wrestle the Flash heap into submission Before we get too carried away, we need to remember that the corruption thread is going to be in the middle of a wild memmove(). Even my laptop can copy memory at a rate of almost 10 gigabytes per second, so we’re going to need to land the copy on to a large runway of heap so that we have enough time to complete the exploit before the copy hits an unmapped page. Getting a large, contiguous heap mapping sounds easy but it is not. If you naively just spray the Flash heap with 512KB ByteArray buffers, you’ll see a large number of process mappings looking like this: 7fd138039000-7fd138679000 rw-p 00000000 00:00 0 7fd138679000-7fd139039000 ---p 00000000 00:00 0 7fd139039000-7fd139fb9000 rw-p 00000000 00:00 0 7fd139fb9000-7fd13a039000 ---p 00000000 00:00 0 7fd13a039000-7fd13ae79000 rw-p 00000000 00:00 0 7fd13ae79000-7fd13b039000 ---p 00000000 00:00 0 [...] At first glance, as security professionals, we might proclaim “great! guard pages!” but what we are looking at here is an accidental inefficiency of the Flash heap. When trying to extend the limit of the heap forwards and failing due to another mapping being in the way, it lets the operating system decide where to put a new mapping. The default Linux heuristic happens to be “just before the last successful mapping”, so the Flash heap will enter a permanent cycle of failing to extend the heap forwards. The “guard pages” come from the fact that the Flash heap (on 64-bit) will reserve address space in 16MB chunks, and commit regions of that as needed, and with granularity of 128KB. It’s quite common for the series of commit requests to not add up exactly to 16MB, leaving a hole in the address space. Such a hole will cause a crash before our exploit is done! To avoid all this and try and obtain a heap that grows forward, we follow the following heuristic: Allocate a 1GB object, which will be placed just before the current heap region. Spray 4KB allocations (the Flash heap block size) to fill in existing free blocks. Spray some more 4KB allocations to cause the heap to extend backwards, into a new 16MB region allocated before the 1GB object. Free the 1GB object. If all has gone well, the heap will look something like this, with green representing the space available for uninterrupted linear growth forward: | committed: 1MB | reserved: 15MB | 1GB hole | committed: ~16MB | ... Step 3: use heap grooming to align our exploitation objects We’re now in good shape to use heap grooming to set up a row of important object allocations in a line, like this: | 8KB buf | 8KB buf | 8KB buf | Vec.<uint>(2000) | Vec.<Object>(1000) | 100MB of bufs | .----- wild copy --------------------------------------------------> In red is the vector we decided to corrupt in step 1, and in green is an object we will deliberately free now that the heap is set up. Before we proceed, there’s one more heap quirk that we need to beware of: as the heap is extended, inline heap metadata is also extended to describe all the new 4KB blocks. This process of extending in-heap metadata creates free regions of blocks inside the heap. This wouldn’t be an issue, but for another quirk: when a block range is returned to the heap free list, it isn’t reallocated in MRU (most recently used) order. Therefore, we mount another heap spray to make sure all 8KB (2 block) heap chunks are allocated, leaving that particular freelist empty. We then free the middle 8KB buffer (in green above) to leave a heap free chunk in a useful place. Since we leave two allocated 8KB buffers either side, the freed chunk will not be coalesced and will be the chosen option for the next 8KB allocation. After all that heap manipulation, we leave ourselves with a range of important objects lined up in a neat row, and with a preceding and free 8KB heap chunk primed to be re-used at the next opportunity. Step 4: light the fuse It’s worth noting that there are platform specific differences in how the sound subsystem initializes. On some platforms, the subsystem initializes and starts asynchronously when play() is called for the first time. For the Chrome Flash plug-in, this is not the case. If you look at the exploit, you’ll see that we have to kick off the subsystem by playing a different sound and then returning to the main event loop. This dance ensures that the second call to play() actually does kick off the wild copy asynchronously. With our heap in nice shape, we trigger the wild memmove() by playing the G711 sound. The wild copy will start immediately and proceed asynchronously so we need to get a move on! The G711 sound decoder object is about 4424 bytes in size, but the heap allocation granularity for sizes >= 4096 is 4096. So, the object will be placed in an 8192-sized chunk -- specifically the one we just freed up if all is well. The wild heap corruption will start within this object and proceed forwards, very quickly corrupting all the following objects that we lined up, including the Vector.<uint> and Vector.<Object>. The moment we’ve pulled the trigger, we spin in a tight ActionScript loop that waits for the length of our Vector.<uint> to change from 2000 to 0xfee1dead. Step 5: defeat ASLR The moment we detect the corrupted Vector.<uint>, we are in business: we can read and write arbitrary 4-byte values off-the-end of the object. As per the heap grooming in step 3, the object directly off the end is the buffer for a Vector.<Object>, which is ideal for us because it contains two important things for us to read: A vtable value into the Flash library, which gives us the location of the code. A pointer to itself, which is very important because it allows us to turn a relative read/write into an absolute read/write. Step 6: ROP-free code execution The exploit proceeds not via a ROP chain, but by rewiring some function pointers in the GOT / PLT machinery. (Note that this relies on RELRO not being present, which it rarely is on common Linux variants and binaries. If RELRO were present, we’d likely simply target vtable pointer rewiring instead.) We have the address of a vtable, and from this, the GOT / PLT function pointers we want are a fixed offset away. There is quite an elegant and simple sequence to get us code execution: Read the function pointer for memmove(), which we know is resolved. Calculate the address of __libc_system, which is a fixed offset from __memmove_ssse3_back which we just read. Write the address of __libc_system to the function pointer for munmap(). The effect of this wiring is that when the program next calls munmap(buffer), it will actually be calling system(buffer). This is a useful primitive because large ByteArray buffers are backed by mmap() / munmap(), and we can control the exact content of the buffer and when it is freed. So we can pass any string we want to system() at will. Step 7: continuation of execution and sandbox To illustrate the level of control we now have over the process, our payload to system() is “killall -STOP chrome; gnome-calculator -e 31337”. This has two effects: Displays the obligatory calculator to prove we have arbitrary code execution. Sends a STOP signal to the existing Chrome processes. This will have the effect of stopping the wild memmove() before it has a chance to crash. As a fun data point, if we attach to the stopped process and look at the wild copy thread, it has managed to copy 50MB(!) of data, even though we tried to make our exploit as fast and simple as possible. At this point, a real exploit that didn’t wish to leave any traces could easily attach to the thread in the middle of the copy and stop the copy without having to kill the thread. Furthermore, the memory corrupted in the process of exploitation could be easily restored. Of course, the sandbox escape is left as an exercise to the user. The system() library call won’t work at all in the Chrome sandbox; when demonstrating the exploit, we’re using the --no-sandbox flag to focus purely on the remote code execution aspect. An exploit inside the sandbox would instead likely rewire function pointers to attack the IPC channels with bad messages, or deploy a ROP chain after all to attack the kernel. Closing notes As always, Project Zero recommends that all memory corruptions are initially assumed to be exploitable. As we showed before in our posts on the Pwn4Fun Safari exploit, the glibc off-by-one NUL byte corruption and the Flash regex exploit, situations that initially look dire for exploitation can sometimes be turned around with a trick or two. Wild copies have a long history of being declared unexploitable, but based on our findings here, we think it likely that most wild copies in complicated multi-threaded software (browsers, browser plug-ins) are likely to be exploitable using the parallel thread corruption method. We publish this finding to encourage developers and vendors to triage wild copies as more serious than previously believed. Posted by Chris Evans at 1:34 PM Sursa: http://googleprojectzero.blogspot.ca/2015/03/taming-wild-copy-parallel-thread.html

Mac OS X 10.10.2 Heap Overflows Authored by Luca Todesco Mac OS X version 10.10.2 suffers from multiple heap overflow vulnerabilities. Included is a xnu local privilege escalation via IOHIDSecurePromptClient injectStringGated heap overflow exploit. Download: Download: Mac OS X 10.10.2 Heap Overflows ? Packet Storm Sursa: Mac OS X 10.10.2 Heap Overflows ? Packet Storm

OpenSSL is a robust, fully featured Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols with full-strength cryptography world-wide. Changes: 12 security vulnerabilities have been addressed. Sursa: OpenSSL Toolkit 1.0.2a ? Packet Storm

New BIOS Implant, Vulnerability Discovery Tool to Debut at CanSecWest by Michael Mimoso When the National Security Agency’s ANT division catalog of surveillance tools was disclosed among the myriad of Snowden revelations, its desire to implant malware into the BIOS of targeted machines was unquestionable. While there’s little evidence of BIOS bootkits in the wild, the ANT catalog and the recent disclosure of the Equation Group’s cyberespionage platform, in particular module NLS_933W.DLL that reprograms firmware from most major vendors, leave little doubt that attacks against hardware are leaving the realm of academics and white hats. Tomorrow at the CanSecWest conference in Vancouver, researchers Corey Kallenberg and Xeno Kovah, formerly of MITRE and founders of startup LegbaCore, will deliver research on new BIOS vulnerabilities and present a working rootkit implant into BIOS. “Most BIOS have protections from modifications,” Kallenberg told Threatpost. “We found a way to automate the discovery of vulnerabilities this space and break past those protections.” Kallenberg said an attacker would need to already have remote access to a compromised computer in order to execute the implant and elevate privileges on the machine through the hardware. Their exploit turns down existing protections in place to prevent re-flashing of the firmware, enabling the implant to be inserted and executed. The devious part of their exploit is that they’ve found a way to insert their agent into System Management Mode, which is used by firmware and runs separately from the operating system, managing various hardware controls. System Management Mode also has access to memory, which puts supposedly secure operating systems such as Tails in the line of fire of the implant. Tails is a privacy-focused operating system that runs off removable media, such as USB stick, and whose aim is privacy and anonymity. “The idea is that if the OS is compromised by an implant, it’s OK to use Tails for communication (all Internet connections are made through the Tor browser) because it’s shielded from the malware that hit the main operating system,” Kallenberg said. “What the implant does is it waits for Tails to boot and scrapes sensitive data out of memory and exfiltrates it out. Our agent listens in the background, Tails doesn’t see it.” Their implant, the researchers said, is able to scrape the secret PGP key Tails uses for encrypted communication, for example. It can also steal passwords and encrypted communication. The implant survives OS re-installation and even Tails’ built-in protections, including its capability of wiping RAM. “We store data in a non-volatile area and it’s not erased,” Kallenberg said. “The idea is to make it obvious that these secure boot disk style things are architecturally vulnerable to attackers who come at you from the BIOS level space.” Kovah said that architectural changes to the BIOS successor UEFI introduced modularity in order to simplify development. But that modularity, which is spelled out in the open source reference implementation of UEFI, is what can be abused. It’s also what many vendors have based their code on. Kovah explained that common code exists in the BIOS variants from different vendors, and that code makes it possible to reliably install implants across the different makes and models. “The open source reference implementation explains how data is passed and there are well-defined locations where to transfer internally to the BIOS,” Kovah said. “You can look at the open source reference to look for patterns and see where the same data exists in closed source versions. Those common reference points define hook locations.” An attacker may place code at those locations, Kovah said, and that up to 100 models from five vendors all share the same code or variants of the same code. “Because of that, you can reliably automate the search of strings for hooking, place hooks, and insert code,” Kovah said. Kovah said an attacker, criminal or nation-state, can also infect the BIOS with physical access to a computer, such as at a border crossing. In a demo shared with Threatpost, using a DediProg flash programmer, Kovah was able to physically clip a connector cable onto the BIOS and download an implant that way. “This can be used at a border crossing, in an Evil Maid attack, or other physical interdiction attacks,” he said. “If you have access, it takes about two minutes once you find the BIOS. The idea is to give this to the unskilled, give them a target, open the computer, connect and press start. It takes about 50 seconds to re-flash the chip. “The point here is that even if you think you’re doing strong op-sec by using Tails or not carrying a hard drive, it doesn’t matter,” Kovah said. “Two minutes of physical access and you can own any OS.” The situation isn’t entirely bleak. The researchers said that vendors do a solid job of patching vulnerabilities that are reported to them, but need to improve secure coding practices and put more effort into vulnerability mitigations. “As time goes on and the cost of exploitation gets higher because more bugs get killed off and new techniques make it harder to exploit, I think that attacking BIOS will be more appealing because of the persistence on that system,” Kallenberg said. Sursa: https://threatpost.com/new-bios-implant-vulnerability-discovery-tool-to-debut-at-cansecwest/111710

China Reveals Its Cyberwar Secrets In an extraordinary official document, Beijing admits it has special units to wage cyberwar—and a lot of them. Is anybody safe? A high-level Chinese military organization has for the first time formally acknowledged that the country’s military and its intelligence community have specialized units for waging war on computer networks. China’s hacking exploits, particularly those aimed at stealing trade secrets from U.S. companies, have been well known for years, and a source of constant tension between Washington and Beijing. But Chinese officials have routinely dismissed allegations that they spy on American corporations or have the ability to damage critical infrastructure, such as electrical power grids and gas pipelines, via cyber attacks. Now it appears that China has dropped the charade. “This is the first time we’ve seen an explicit acknowledgement of the existence of China’s secretive cyber-warfare forces from the Chinese side,” says Joe McReynolds, who researches the country’s network warfare strategy, doctrine, and capabilities at the Center for Intelligence Research and Analysis. McReynolds told The Daily Beast the acknowledgement of China’s cyber operations is contained in the latest edition of an influential publication, The Science of Military Strategy, which is put out by the top research institute of the People’s Liberation Army and is closely read by Western analysts and the U.S. intelligence community. The document is produced “once in a generation,” McReynolds said, and is widely seen as one of the best windows into Chinese strategy. The Pentagon cited the previous edition (PDF), published in 1999, for its authoritative description of China’s “comprehensive view of warfare,” which includes operations in cyberspace. “This study is a big deal when it’s released,” McReynolds said, and the current edition marks “the first time they’ve come out and said, ‘Yes, we do in fact have network attack forces, and we have teams on both the military and civilian-government sides,’” including inside China’s equivalents of the CIA and the FBI. The acknowledgment could have political and diplomatic implications for China’s relationship with the United States and other Western powers. “It means that the Chinese have discarded their fig leaf of quasi-plausible deniability,” McReynolds said. “As recently as 2013, official PLA [People’s Liberation Army] publications have issued blanket denials such as, ‘The Chinese military has never supported any hacker attack or hacking activities.’ They can’t make that claim anymore.” U.S. officials have spent years marshaling evidence of China’s cyber capabilities and have been escalating efforts to stop cyber spying. Last year, the Justice Department took the unprecedented step of indicting five Chinese military officials for hacking into U.S. companies and stealing their proprietary information to give Chinese firms a leg up on the global market. That indictment was met with more denials, which have continued even past the publication of the latest Science of Military Strategy, which has taken months to translate, McReynolds said, and has not been publicized outside the ranks of China analysts. “When asked, the Chinese as recently as a month ago denied they had a cyber command,” James Lewis, a senior fellow at the Center for Strategic Studies and a leading expert on China’s cyber capabilities, told The Daily Beast. Lewis said that the new revelations won’t come as “earth-shattering” to analysts and experts who closely follow statements by Chinese officials, because “we all assumed they were lying.” “But it’s interesting, and people outside the community won’t know it,” Lewis said. He compared the revelation to China’s testing, in 2007, of an anti-satellite missile, “which came after they had for years stoutly denied that they were building space weapons.” China has divided its cyber warfare forces into three types, said McReynolds, whose analysis is included in his forthcoming book, China’s Evolving Military Strategy, which will be published in October. First, there are what the Chinese call “specialized military network warfare forces” consisting of operational military units “employed for carrying out network attack and defense,” McReynolds said. Second, China has teams of specialists in civilian organizations that “have been authorized by the military to carry out network warfare operations.” Those civilian organizations include the Ministry of State Security, or MSS, which is essentially China’s version of CIA, and the Ministry of Public Security (its FBI). Finally, there are “external entities” outside the government “that can be organized and mobilized for network warfare operations,” McReynolds said. As to which of those groups is responsible for targeting American companies to steal their secrets, the short answer, says McReynolds: “They all do it.” Espionage by the PLA has been extensively documented, McReynolds said. And a Chinese hacking unit dubbed Axiom that has been linked to intrusions against Fortune 500 companies, journalists, and pro-democracy groups is reportedly an MSS actor. He noted that there are also many ways that Chinese civilians have been seen assisting in industrial espionage, including through “hack-for-cash” operations. Based on other PLA writings, it appears that the military would most likely handle any targeting of critical infrastructure, McReynolds said. Now that China is coming clean about its cyber warfare forces, other countries may question whether they can safely cooperate with the government on combating cybercrime. The Ministry of Public Security (MPS), for instance, has assisted more than 50 countries with investigations of more than a thousands cases of cybercrime over the past decade, and China has set up bilateral law enforcement cooperation with more than 30 countries, including the United States, the United Kingdom, Germany, and Russia, McReynolds said. “With the Chinese now explicitly acknowledging that the [ministry] has network warfare forces stationed within it, the United States and other targets of Chinese state-sponsored hacking will have to weigh carefully whether cooperation with the MPS on cybercrime is worth the risks,” he said. McReynolds also saw signs of a potential power struggle between the People’s Liberation Army and civilian government agencies like the Ministry of Public Security over who really runs cyber operations within the Chinese system. Those civilian cyber forces operated under the PLA’s “authorization,” according to the Chinese document. “As unprecedented as it is to have the Chinese military acknowledge the existence of its network attack forces, having the PLA announce the existence of such secretive forces inside the civilian government is particularly unusual, and strikes me as an attempt to ‘plant the flag’ for the PLA,” McReynolds says. The new analysis of China’s cyber operations has taken a long time to produce, in part because the latest edition of the The Science of Military Strategy wasn’t released until December 2013, McReynolds said. “It takes a while for this sort of information to filter out into the Western PLA-watcher community, especially since there’s no English translation available yet. It was only last summer that the first of us in the community started to obtain copies of the new SMS and go through its contents; it’s hundreds of pages long.” McReynolds, who said he reads Chinese, also ran his translations by analysts fluent in the language to ensure the accuracy of his work, he said. China isn’t the only major U.S. adversary with advanced military cyber operations. Russia is a “near peer” to the United States, former National Security Agency Director and Cyber Command chief General Keith Alexander said in 2010. The country’s use of cyber offensive operations has been documented both in Georgia in 2008 and more recently with Russia’s invasion of Crimea in 2014. Those operations, conducted in tandem with traditional combat operations, have been aimed at disrupting adversaries’ communications systems, including public websites. Experts generally agree that Russia, China, and the United States have the most advanced and sophisticated cyber warfare forces. But Iran has been quickly gaining new capabilities and demonstrated a willingness to use them, as with a massive attack on U.S. bank websites in 2012. North Korea has also ramped up its cyber operations, most notably with the hacking of Sony Pictures Entertainment last year, which prompted the Obama administration to impose new economic sanctions on the hermit kingdom. Eric Rosenbach, an assistant secretary of defense in charge of homeland defense and global security isssues, has said that some five dozen countries are building a military-cyber operation, equivalent to the United States’ Cyber Command. Sursa: http://www.thedailybeast.com/articles/2015/03/18/china-reveals-its-cyber-war-secrets.html

Pwn2Own 2015: Day Two results Dustin_Childs| March 19, 2015 The second and final day of Pwn2Own 2015 saw successful exploits by both entrants against four products, with each going after multiple targets and collecting a total of $235,000. This brings the two-day payout total to $552,500, not including the value of the laptops, ZDI points, and other prizes given to winning researchers. Here’s the highlights of the day’s proceedings. ilxu1a started off Day Two by taking down Mozilla Firefox with an out-of-bounds read/write vulnerability leading to medium-integrity code execution. It happened so quickly that those of us who blinked missed it — although in our defense, it was sub-second execution. He reports he found the bug through static analysis, which is truly impressive. ilxu1a received $15,000 USD for the bug. For the first of his three targets, JungHoon Lee (lokihardt) took out 64-bit Internet Explorer 11 with a time-of-check to time-of-use (TOCTOU) vulnerability allowing for read/write privileges. He evaded all the defensive mechanisms by using a sandbox escape through privileged JavaScript injection, all of which resulted in medium-integrity code execution. This got his day started out right with a payout of $65,000 USD. Next, JungHoon Lee (lokihardt) demonstrated an exploit that affects both the stable and beta versions of Google Chrome. He leveraged a buffer overflow race condition in Chrome, then used an info leak and race condition in two Windows kernel drivers to get SYSTEM access. With all of this, lokihardt managed to get the single biggest payout of the competition, not to mention the single biggest payout in Pwn2Own history: $75,000 USD for the Chrome bug, an extra $25,000 for the privilege escalation to SYSTEM, and another $10,000 from Google for hitting the beta version for a grand total of $110,000. To put it another way, lokihardt earned roughly $916 a second for his two-minute demonstration. There are times when “Wow” just isn’t enough. For his final act of the competition, JungHoon Lee (lokihardt) took out Apple Safari using a use-after-free (UAF) vulnerability in an uninitialized stack pointer in the browser and bypassed the sandbox for code execution. That netted him another $50,000 USD and brought his daily total to $225,000. This is an amazing accomplishment for anyone, but it’s especially impressive considering he is an individual competitor rather than a team. Well done. The final entrant in Pwn2Own 2015, ilxu1a, attempted to exploit Google Chrome, but ran out of time before he could get his code working. He told us he was having issues with his info leak. While not a winner on this round, he has won twice before and showed some lovely research on the topic. I’m sure we’ll see him again. As with every Pwn2Own, all vulnerabilities were disclosed to their respective vendors in our “Chamber of Disclosures,” and each vendor is working to fix these bugs through their own processes. The final numbers for Pwn2Own 2015 are quite impressive: 5 bugs in the Windows operating system 4 bugs in Internet Explorer 11 3 bugs in Mozilla Firefox 3 bugs in Adobe Reader 3 bugs in Adobe Flash 2 bugs in Apple Safari 1 bug in Google Chrome $442,500 USD bounty paid out to researchers Again, congratulations to all of this year’s champions. It was a great time for us, and we saw some amazing research throughout the contest. Thanks again to our co-sponsors at Google Project Zero. See you next year! Sursa: Pwn2Own 2015: Day Two results - HP Enterprise Business Community

Installers Installs Go and a text editor. Windows OSX (32 bit, 64 bit) The Book An Introduction to Programming in Go. Copyright © 2012 by Caleb Doxsey ISBN: 978-1478355823 This book is available for purchase at Amazon.com in Kindle or Paperback. It is available for free online below or in PDF form. Questions, comments, corrections or concerns can be sent to Caleb Doxsey. Table of Contents Getting Started Files and Folders The Terminal Text Editors Go Tools Your First Program How to Read a Go Program [*]Types Numbers Strings Booleans [*]Variables How to Name a Variable Scope Constants Defining Multiple Variables An Example Program [*]Control Structures For If Switch [*]Arrays, Slices and Maps Arrays Slices Maps [*]Functions Your Second Function Returning Multiple Values Variadic Functions Closure Recursion Defer, Panic & Recover [*]Pointers The * and & operators new [*]Structs and Interfaces Structs Methods Interfaces [*]Concurrency Goroutines Channels [*]Packages Creating Packages Documentation [*]Testing [*]The Core Packages Strings Input / Output Files & Folders Errors Containers & Sort Hashes & Cryptography Servers Parsing Command Line Arguments Synchronization Primitives [*]Next Steps Study the Masters Make Something Team Up Additional Resources Video tutorial on how to build tries in Go © 2014 Caleb Doxsey. Cover Art: © 2012 Abigail Doxsey Anderson. All Rights Reserved. Sursa: http://www.golang-book.com/

XPATH Assisted XXE Attacks DannyChrastil| March 17, 2015 I was in a coffee bar with some good friends of mine the other day and one of them asked me “Danny, if in one hand you have XPath Injection, and in the other XXE Processing… which would you choose?” With a wry smile I responded to him, “Put your hands together!” (miss the reference? )When testing applications which are employing XML, whether it be a web service for a mobile application or an ajax-mashup website, two of the main vulnerabilities you will see and hear about are XPath injection and XXE (XML External Entity) processing. While each of these on their own are interesting vulnerabilities, there is a unique situation that allows you to chain the two together in order to read data off a target system. XPath Injection XML documents act as a data store or database for applications. You can store large amounts of data in a hierarchical structure which can then be queried by the application the same way you would query a database. This querying protocol for XML is called XPath. Just like SQL queries can be vulnerable to injection attacks, so can XPath queries. If user-supplied data is not sanitized before being applied to the XPath query, an attacker could perform an injection attack much like the following: Query: $xquery = "//Customer[username/text()='" . $_POST[‘username’] . "' AND password/text()='" . $_POST("passwd") . "']"; Attack Request: username=danny’ or 1=1 or ‘1’=’1&password=testing Resulting XPath Query: //Customer[(username/text()='danny’ or 1=1) or (‘1’=’1' AND password/text()='testing')] This injection would match and return results for all of the customers in the XML document instead of data only belonging to ‘danny’. While this attack can be very powerful, it also has its limitations. Unlike SQL, XPath has very limited interactions with the OS and system files of the web server. There is a function in XPath called “doc()” that can read both local and remote files as long as they are XML documents. This is great if you can find a XML file on the server which contains sensitive information, but in most cases this won’t be helpful in trying to access /etc/passwd, etc. XXE Processing XXE stands for XML External Entity Processing. The XML data structure allows for elements called entities which are used as data variables to be used within the XML body. An XXE attack is when the user can control the XML structure that is sent along with the request to the server. If an attacker can create their own entity then they can perform attacks such as sensitive file disclosure, denial of server, port scanning and more. Attacker controlled XML: <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foobar [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foobar>&xxe;</foobar> This attack would load the file “/etc/passwd” from the server and return the data within the <foobar> element to the user. The attacker could get creative and load other files such as CMS config files for database credentials. XPath assisted XXE XPath Injection and XXE Processing are not commonly found together within the same application. So what if you find XPath Injection within a search form on a site which doesn’t contain sensitive information or authentication. Apart from changing the results which are displayed in the search response, there isn’t much to do. If only we had XXE to help us read files off the file system. Remember that XPath “doc()” function that can only load XML documents? Because “doc()” can also load external XML documents, an attacker could force the application to load an evil XML document hosted on their own server. How does this help us read sensitive files on the target server? If the attacker creates the evil XML document to contain XXE processing that loads /etc/passwd. When this XML is loaded on the target server it will then load the file corresponding to its own file system, not the attackers. How to Protect Yourself Because this attack is chaining two vulnerabilities together, it is important that both are addressed in order to mitigate the risk. XPath Injection is similar to other injection vulnerabilities in that the best approach to remediation is by implementing thorough white list validation and input sanitization on any user supplied data; in this case, anything going into the XPath query. Theoretically, if the user supplied input is being validated before building the XPath query, then the attacker would not be able to inject the “doc()” function to load the malicious XML file; however, it would be best practice to disable the “doc()” function completely if it is not required by the application. If that is not a viable option, then the next step would be to disallow any remote calls by the “doc()” function only allowing local XML files to be loaded. Here at HP Fortify on Demand, we are working to detect this issue for all of our customers' sites and provide them detailed remediation steps. Reach out to us with any questions Sursa: http://h30499.www3.hp.com/t5/Fortify-Application-Security/XPATH-Assisted-XXE-Attacks/ba-p/6721576

Te-ai insurat ba?

Fa public. 90 days policy de la Google Project Zero e cam mult. dekeeu's Disclosure Policy: 30 days.

Adu si niste argumente daca ai facut o afirmatie.

The job's daily activities include design, development, maintenance and integration of business applications. C# will be the usual programming language, Visual Studio - the development environment and Microsoft SQL Server - the data storage engine. Responsibilities: • Building new systems with ASP.MVC , ASP.NET , SQL Server 2008/ 2012 , EntityFramework and Linq • Developing new functionality on our existing software products • Leading/mentoring IT staff and sharing knowledge through knowledge-sharing presentations • Participating in a small, experienced, energetic development team. Requirements: • Solid knowledge of C# and .NET Framework, OOP concepts, algorithms and data structures – minimum 4 years of experience • Web development experience (ASP.MVC ,ASP.NET, Java script, AJAX, CSS, JSON, JQUERY); - minimum 4 years of experience • Very good knowledge of T-SQL and relational database design; - minimum 4 years of experience • Graduate of Computer Science/Cybernetics/Information Technology/Electronics College; • Fluent in English; • Ability and willingness to work as part of a team of developers; • Learning oriented person. Additional advantage: • Active Reports, SQL Reporting Services • Java & Install Shield knowledge • Active Directory knowledge • Knowledge of WCF Web Services, WCF Data Services Bestjobs: Application Developer la S.C. KPMG ROMANIA SRL, BUCURESTI - BestJobs Cine e interesat imi poate trimite CV-ul ca sa ajunga mai repede unde trebuie.

Parca aveai nevoie de DVD/USB bootabil cu Windows pentru asta.

Bla bla... Bootezi din orice distributie Live de Linux, si in partitia de Windows inlocuiesti din System32 Utilman.exe cu cmd.exe. Bootezi in Windows si apesi pe butonul din stanga jos si esti "NT Authority\System". User add + localgroup administrators sau schimbi parola de admin local si gata.