
NO! Stop it!
"... Its the end users that are still the biggest problem. ..."
Stop to blame the end user. If a brake fails, usually it is not the car driver's fault.
No regards, HA
26 publicly visible posts • joined 8 May 2010
".... Much better to verify that nothing can run on your critical system unless and until it's been confirmed as good to a high level of confidence, Ken Thompson's Reflections on trusting trust paper notwithstanding. ..."
Known since at least thirty years.
"Property: Executable by ...[monitor]" as given in ACLs of TOPS10, a little bit later by RACF of IBM, and then as a label in LSPP.....
Remarks by HA
"... So in the absence of a comprehensive solution, [...], and deal with the APTs via a gateway appliance. That has the subsidiary advabtage ... "
Though overlooked too often in Germany, this approach has already been enforced by (technical) rules. See points M2.73 and M2.75 in "IT Grundschutz" .
Regards, HA
"Whitelisting by Black Hats" has been observed since September 2007. References have been published .
Please refer to http://www.heise.de/security/news/foren/S-Ich-versuche-es-zu-erkaleren-soweit-ich-es-verstanden-habe/forum-128326/msg-14007655/read/?zanpid=1728371198125224961 and following posts.
I explained it again in topic 1 of http://websicherheit.wordpress.com/2011/08/06/einbruch-bei-rsa-offenbar-aus-china/...
It must be taken for sure, that this kind of camouflage has been applied since more than five years.
<sarcasm> RSA should remember the mails they received ... </sarcasm>
HA
Alphabet V.A.1 was spread since autumn 2007 according to local backups. It was hidden in "Verbatim.exe" , which was run at startup from USB-Sticks by Verbatim. Hints occurred July 2011, but up to now very little information has leaked into public about this trojan.
Best, adamsh
1) Marko Rogge discovered this effect trying to wipe out an USB stick, a flash device like a SSD. He published his discovery in https://www.xing.com/net/priedb263x/sicherheit/application-layer-bio-crypto-pen-voip-uce-was-19413/verschlusselung-kann-trugerisch-sein-28202781/p0 and published a white paper http://www.marko-rogge.de/truecrypthinweis.pdf.
2) I was able to verify this effect with older USB sticks and was able to explain this effect due to wear levelling procedures, see https://www.xing.com/net/priedb263x/sicherheit/application-layer-bio-crypto-pen-voip-uce-was-19413/verschlusselung-kann-trugerisch-sein-28202781/28223883/#28223883.
During research against SSD the ATA command set enlightened the background:
3) ATA command 0xf3, "security erase unit", requires only overwriting of USER DATA AREAS, cite "....When Normal Erase mode is specified, the SECURITY ERASE UNIT command shall write binary zeroes to all user data areas (as determined by READ NATIVE MAX or READ NATIVE MAX EXT). IDENTIFY DEVICE or IDENTIFY PACKET DEVICE word 89 gives an estimate of the time required to complete the erasure."
Bingo. They just use their routines for "write sectors" / "erase sectors", writing only to "user data areas" obeying their own wear levelling strategies... See point 2) ;->
4) "The Enhanced Erase mode is optional" and "In Enhanced Erase mode, all previously written user data shall be overwritten, including sectors that are no longer in use due to reallocation..."
To make it clear. Only if and if a feature beyond the standard ("optional") has been implemented, AND the device driver checks against a bit pattern and sets it, the ATA-drive might indeed clear all previously written data .....
5) To summarize it:
Above mentioned behaviour is correct in the sense of the ATA command set.
Everyone could have learned it if they read the data sheets and standards.
Best, Hans Adams
> Technically, unix is also vulnerable if you have set up your LD_LIBRARY_PATH to include the
> current directory before the /var/lib paths, however here you can customize it and no sane person
> would do this...
No! This is a bug / feature of GNU/Linux, NOT necessarily one of UNIX, as UNIX is a trademark of an specification formerly by USL. Solaris is the best known implementation of UNIX (as defined by USL), therefor one should follow the precautions Solaris has taken.
See http://docs.sun.com/app/docs/doc/816-0210/6m6nb7md6?l=all&a=view ...
A setuid-program should never follow LD_LIBRARY_PATH .....
Solaris allows to jail applications, which are regarded not beeing full trustworthy, in zones. Applications requiring untrustworthy libs would end in jail called zones. Period.
tells HA
Hallo,
when I am asked to execute an order, I have to limit myself to orders given by those who I trust or have to trust (instructors, some [computer] programs, I myself?). Never I may follow those who want me to commit a crime ;->
A software system run under and exposing a certain identity may only trust its own components (libs, taks etc...) or components from other identies the executing identity trusts.
Commonly a software system only needs its own libraries (and subtasks) and those offered by the identity "system". Why should an unidentified component be trusted?
Micorosft itself has built up a whole PKI and forces vendors to sign their components digitally just to avoid execution of untrusted components. Microsoft statement,“Hence, this issue cannot directly be addressed in Windows without breaking expected functionality. Instead, it requires developers to ensure they code secure library loads.", foils the security policy of Microsoft itself.
Evolving dangers by executing untrusted components have been known since the early sixties of the last century, IBM and BULL published basic results around 1966....Some of these results founded the security design of the AS/400 under OS/400.
RBAC/MAC forces a linking policy for processes / tasks run under certain and/or predefined identities. Given this failure Microsoft can not obey basic requirements to fulfill higher protection profiles.
Solaris 10 never allows linking of untrusted libraries against setuid programs or programs executed under uid 0, see http://docs.sun.com/app/docs/doc/816-5165/ld.so.1-1?l=all&a=view, keyword "security".
In summary Microsoft did not learn its lessons from the last half century, and even foils its own security policies --- once again an epic fail.
Sorry, HA
Please (re-)calculate the entropy of those generated passwords!
Please bear in mind the reduced entropy due to known syllables!
Please bear in mind that a substitute cipher does not change the entropy!
Please discuss the (metric) distance of your passwords generated by your algorithm! How easy will another password be derived from an already known?
Four random characters (your salt) encode at most 24 bits of entropy. How should these help?
Head banging, Hans Adams
If you once got access to the encrypted pass phrase ......There are more ways to compromise your pass phrase.
Well known exponential back off might help, if one has to run a dump brute force attack, as those outdated will die it renders this old approach useless (Netware 3.12)....
best regards, HA
The article covers:
1. SGEMM
2. MC
3. Conv
4. FFT
5. SAXPY
6. LBM
7. Solv
8. SpMV
9. GJK
10. Sort
11. RC
12. Search
13. Hist
14. Bilat
All of the above will work with floating point numbers, up to my best knowledge floating point calculation is required for 1,2,5,6,7,8.
Data flow approach is inappropriate for at least 1, 10 and 12....
For heaven's sake how does this workload compare to inverting a key by (modified) brute force, which is generate - encode - compare in a data flow approach in integer and bit operations????
As performance measures of integer and bit-wise operations are required, but performance of floating point operations to memory is given, you compare processors against inappropriate performance measures, here their floating point performance. Thereby you underestimate the required performance of integer and bitwise operations offered by signal and graphic processors by far.
Head banging, HA
Just to remember:
1a) Characters in passwords are NOT uniformly distributed.
1b) The sequence of characters in the password build Markov chains of finite orders (2-8).
1c) a) and b) offer ample opportunities for attacks based on statistics.
2) Printable characters encode about six bits, NOT eight bits as claimed often. A password with sixteen characters encodes about 100 bits, NOT 128 bits as claimed. This password is indeed a billion (!) easier (less effort) to crack than claimed.
3) The available integer performance (NOT number crunching as claimed in article) per buck, driven by improvements in GPUs and signal processors for image processing, has already increased by the factor of 10 million since 1990. About 100 Billion (!) integer operation / second are offered for less then 1000 US $ per graphic subsystem. Some workstation vendors offer nineteen of those graphic subsystems, a cage, a main cpu, disks and power supply for about 20000 EURs, about 27000 US $, yielding a sustained integer performance of about one trillion (!) operations / second.
In summary:
Passwords never reached the complexity/entropy expected, due to inherent limits. Meanwhile enough processing power is available to crack actual passwords in days with high success rate...
Therefor passwords / password based authentification must be regarded untrustworthy....
All I wrote above should be common knowledge here, HA expects.
These kind of attacks have been observed since more than ten years. The idea behind is to publish many different implementations of the same or very similar malware, each implementation is spread very seldom (10 to 50).
So this malware will be always hidden under the RADAR of most security firms as occurrences of each are too few to trigger any reaction.
Often far worse compromised systems are regarded clean and trustworthy, as magic scanner xyz did not reccoggnize an malware on them --- with desastrous results.
Assembler/machine language gave as the first option to implement polymorphous code, the macro language(s) of the Office packets made it easier, and JRE includign JIT gave us a working development enivronment on every PC for polymorphous malicious code?
Remarks, HA
Citation from http://www.matousec.com/info/articles/khobe-8.0-earthquake-for-windows-desktop-security-software.php
" ....
The problem
The code of system services runs on IRQL PASSIVE_LEVEL which also applies to their hook handlers. Code running at this level can access pageable memory and, when the scheduler decides, might be preempted by another thread. And the scheduler plays the key role in the argument-switch attack. ....
Before the scheduler switches back to the hook handler, many threads might use the processor for some time, including other threads of the application that called NtLoadDriver. ....
When the scheduler switch thread context back to the thread executing the hook handler, the original system service is invoked and might load driver which name was not subject of any security check made by the security software. And this is exactly how the argument-switch attack works. .....
"
The bomb is hidden elsewhere. It can not be deactivated by changing dispatch priorities.
best, Hans Adams