* Posts by kurtseifried

6 publicly visible posts • joined 9 Mar 2016

Remember Norton 360's bundled cryptominer? Irritated folk realise Ethereum crafter is tricky to delete

kurtseifried

Classic gift card balance "exploit"

From the GSD entry GSD-2022-1000002 (https://github.com/cloudsecurityalliance/gsd-database/blob/main/2022/1000xxx/GSD-2022-1000002.json)

Norton AntiVirus now includes an Ethereum crypto miner that has several problems including deceptive rewards program and difficulty in uninstalling it.

Norton keeps 15% of all Ethereum mining proceeds and "pays" the remainder into a users "Norton Crypto Wallet" which is hosted by Norton. It should be noted that the Norton Crypto Wallet cannot be used to make Ethereum transactions, but can only be used to transfer value to a Coinbase account once a certain minimum threshold of value is accrued. The Norton crypto mining and Norton Crypto Wallet are effectively a gift card system where the money can be withdrawn, but not unless a certain balance is available. It should also be noted that the Norton Crypto mining software is reportedly very difficult to uninstall, requiring administrative level privileges, and even then reports indicate effective removal is difficult.

15-year-old security hole HTTPoxy returns to menace websites – it has a name, logo too

kurtseifried

Re: Perl? Perl!

So part of the problem is that there are about 10,000 major Open Source projects (purely guessing, but Red Hat ships roughly that # of packages now) with tens to tens of thousand of commits per year. Sorting out the wheat from the chaff is tough. One approach to this is to very identify security related commits and get them labeled with CVE identifiers if they are indeed a vulnerability (as this one would have been), once things have CVE's (and are listed in the CVE databases) they become much more findable/useful (drinking from a garden hose instead of a fire hose).

To this end CVE is moving to a federated model, currently the DWF (https://distributedweaknessfiling.org/) is the root for all Open Source. So if you see something, report something! If it's public and not needing an embargo then please email the oss-security@lists.openwall.com list (you do not need to be subscribed to post). If it is private or maybe needs sensitive handling please notify us (Red Hat) at secalert@redhat.com or CER T (https://vulcoord.cert.org/VulReport/). For closed source CERT is also a good bet.

kurtseifried

Re: From the linked article

The problem is not the header, you should be able to pass any headers around that you want (often people create and use headers for internal identification of requests, or have remote JavaScript clients using special headers). The problem is that due to popular convention many web servers simply prefix HTTP_ to the headers when turning them into environmental variables, and thus the name space conflict.

The good news is that Apache and others are preventing the Proxy header specifically from being turned into an environmental variable, but we can't just automatically drop it because that is unexpected and somewhat rude. Server operators are of course free to simply block or drop the header as they see fit.

CVE bug system has bugs – quick, use this alternative, say hackers

kurtseifried

Re: F***ing Hell

Because someone finds a flaw that affects several dozen products, or even hundreds of products (CVE-2009-3555), and many larger products and security related software (that get audited a lot) have a lot of flaws to be dealt with.

Then there is the consumption of updates aspect, there is more than one way to fix a flaw, for example an XSS flaw in a web application, but you can block this with mod_security and an appropriate rule. How does mod_security communicate which things they have fixed easily when most web apps have dozens of XSS flaws found at various times.

When communicating and coordinating these security vulnerabilities we need a common naming scheme, especially when we're handling thousands of vulnerabilities per year.

kurtseifried

To be honest it's actually pretty easy. For one thing in the Open Source world I just ask them for an example of the vulnerable code/code fix, or for how exploitation occurs (e.g. with XSS it's usually trivial to demo), if they can't provide either then chances are they don't really understand the vulnerable enough to be asking for an identifier.

For the closed source world it's obviously a bit tougher, which is why DWF number assignments are farmed out as much as possible to vendors, who can and do verify the issues (an then need an identifier for them).

So if someone attempts to flood the DWF with stuff, Open Source stuff would be trivial to weed out, and for closed source we'd simply base it on various things like "is this person well known/have a good track record?" and "can we easily verify this" and so on.

kurtseifried

We're not claiming copyright on DWF just to be clear. These are like phone numbers or GPS coordinates, just factual bits of information to make finding other bits of information (security vulnerability related) much more easy.