lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
From: jftucker at gmail.com (James Tucker)
Subject: AV companies better hire good lawyers soon.

Um, I might suggest one thing, USE YOUR EXCLUSIONS! almost all of the
anti-virus programs support exclusions, although this is not a best
case solution, it should work.

Anyone who does not know why you should be required to submit every
program you ever make to AV companies needs to think about this a
little more.
1. How is a submitted program to be veto'd as safe? (what if a virus
is submitted?)
2. How are the AV companies to fund checking every application ever submitted?
3. What is it that your programs are doing which is showing up in the
heuristics?!?!?!

As far as a writer checking to see that their software is compatible
across all possible local system configurations, that is an
intractable problem, don't be so silly. Obviously within reason you
need to ensure that it does not replace anything, does not rely upon
libraries which are often changed / removed (or that are only
installed on the development system), does not change system
configurations unless absolutely required. Meanwhile, configurations
and libraries which are standard to the platform (say, JVM SDK or OS
SDK for examples) should be re-used wherever possible, to create
standardised software where common points of failure can be fixed
resulting in common fixes. It is important that consideration is taken
to respecting the documentation when using built in libraries. (This
is not always a good rule for security, the whole single points of
failure problem). Doing contrary to any of the prior rules will create
software which may suffer issues caused by some outside influence,
furthermore it may become an outside influence for some other
software, this is not required functionality and is bad software
design. Applications should clearly be designed to be either static,
or dynamic as appropriate (i.e. if the OS can just be configured to do
it on its own, then just configure the OS to do it), not half casts in
between produced with poor specifications.

AV companies obviously don't follow all the rules, but they never
could by purpose could they? (how are you supposed to not affect other
software when that is your purpose?) AV programs are designed to
protect your data, false positives are not common but are not
practically possible to prevent in all cases. At the end of the day,
binary code only has so many possible permutations and combinations
(very very many, but so many), furthermore faster heuristic checking
partially relies on shorter (and thus normally more generic) rules; as
with many things IT this results in a trade off between accuracy and
performance.

I am sympathetic to any developer who comes up against this problem,
and we are all probably aware of the business damage that can be done
by such an event; however as a developer you should be capable of
realising the size of the problems involved here. The only true
resolution is to get hold of someone (preferably high on the ladder)
in real life (phone / physical).

What I am not sympathetic about is the fact that the story about the
ISP dialler which is blocked by McAffee interests me purely because,
if the system could no longer dial as a result of this false
identification; the software had placed itself in a point of reliance
somewhere between ppp, tcp/ip, and the drivers. This is non-conformist
(does not just configure the OS, which is how it should be done), not
recommended by Microsoft, or any other major software development
company. Use what is available but reliable first, then build your own
stuff. Of course I might have a completely wrong handle on why the
connections stopped working after this software was removed.
Personally I hate customised dialer applications and frequently remove
them by hand; from the sounds of it the quoted application is such a
piece of software. In terms of provided functionality for the cost of
a running program (and sometimes a service too) vs. the (lack of)
increased functionality over the OS itself; many of these applications
I would consider malware anyway.

I showed the ISPWizard site and software to several other
professionals and the reaction is always the same... "eeeewwww!".
Whilst such a program might work really well (and arguably had good
purpose back when it was "hard" to connect to an ISP, on win95 or some
derivation of), its not exactly "good" software. It provides 2
features over the normal Microsoft wizard (which you can add this
functionality to anyway, and the dialer partially just does this), 1.
Provides a selectable list of service numbers, 2. Automagically sets
up a pile of ISP abuse on your system (branding pasted everywhere).
"Setup programs created are very small and self contained (Around
300k)" this is not a feature, 300k is a huge amount of data to front
an Internet dial up wizard IMO, especially as it is essentially
carrying how-to-configure-a-system scripts. At least the price point
is very reasonable, but I would still just distribute DUN configs
(which aren't even binaries, so no more worries here).


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ