* Posts by adamsh

26 publicly visible posts • joined 8 May 2010

Flooding market with cheap antivirus kit isn't going to help ANYONE


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


Re: AV gives minor protection to weak systems

".... 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


Re: Try this solution ...

Cracked since centuries. Problem remains "cat evil.code | sh"....

Regads, HA


Re: Affordable APT protection?

"... 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

to "You're not cool enough for some malware" referring RSA ---- Critical Comment....


to "You're not cool enough for some malware" referring RSA ---- Critical Comment....

"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>


Schneier spanks AV industry over Flame failures


Re: Reactive broken model?

Are all installers trustworthy? asks adamsh


Re: Reactive broken model?

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

Attack of the clones: Researcher pwns SecureID token system


Betrayal --- Bad Excuses

If the researchers are correct, this attack will work of every image dump of a system disk. ---- Rootkits are not required --- by no means.


Patch Tuesday leaves Duqu 0-day for another day


A claim, yet to be proved

Cite: " ...Neither the Active Directory bug nor the TCP/IP stack flaw have been weaponised into exploits ..."

Would you please prove this claim?

Will you make us believe indeed, that you know everything worked upon out there?

HA wonders.....

Flash drives dangerously hard to purge of sensitive data

Thumb Up

No --- you are not alone! We proved it a year ago!

Have a look at http://forums.theregister.co.uk/post/992361.

Regards, HA


Behaviour is correct according to ATA standard

Have a look at the ATA standard, or at topic 4) in http://forums.theregister.co.uk/post/992361.

Regards, HA


Will NOT work, as it is NOT supposed to work

Have a look at the ATA standard, or at topic 4) in http://forums.theregister.co.uk/post/992361.

Regards, HA


Already discovered a year ago - wiping a flash device need not work

You are correct, but it has been discovered a year ago.



Already proven wrong.

see http://www.marko-rogge.de/truecrypthinweis.pdf.

Best, HA


Already discovered a year ago - wiping a flash device need not work

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

But it said so in the manual


Linux would not help

As Linux does not provide a native ZFS. Under Linux ZFS is only available as FUSE.... *BSD and all kinds of current Solaris are much more approbriate, reminds HA.

Microsoft confirms code-execution bug in Windows apps


Though NSA told them about th problem twelve years ago .....

> And they still can't get it right!

You are right, see pages 105 ff. in http://packetstormsecurity.org/NT/audit/NSAGuidePlus.PDF

best regards, Hans Adams


Not quite true. A bug of Linux, seldomly seen on UNIX (tm)

> 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


An old issue since the seventies of the last century


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

Short passwords 'hopelessly inadequate', say boffins


For heaven's sake ---- be warned --- do not follow http://ht.ly/2r1nK

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


Longer .... exponential back off

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

Thumb Down

Performance of data flow integer operations is required, .....

The article covers:


2. MC

3. Conv

4. FFT


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


Issues are best known, partly since Shannon!

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.

Regional banking Trojans sneak past security defences


What is new about it?

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

New attack bypasses virtually all AV protection


The bomb is hidden elsewhere ......

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