NickTheGreek

The Israeli security researcher Barak Tawily a vulnerability tracked as CVE-2018-6389 that could be exploited to trigger DoS condition of WordPress websites. The expert explained that the CVE-2018-6389 flaw is an application-level DoS issued that affects the WordPress CMS and that could be exploited by an attacker even without a massive amount of malicious traffic. “In this article I am going to explain how Denial of Service can easily be caused to almost any WordPress website online, and how you can patch your WordPress website in order to avoid this vulnerability being exploited.” reads the analysis of the expert. Tawily revealed that the flaw exists in almost all versions of WordPress released in last nine years, including the latest one (Version 4.9.2). The flaw affects the “load-scripts.php” WordPress script, it receives a parameter called load[] with value is ‘jquery-ui-core’. In the response, the CMS provides the JS module ‘jQuery UI Core’ that was requested. As you know, WordPress is open-source project, for this reason, it was easy for the expert to perform code review and analyzed the feature in detail. The load-scripts.php file was designed for WordPress admins and allows to load multiple JavaScript files into a single request, but the researcher noticed that that is is possible to call the function before login allowing anyone to invoke it. The response provided by the WordPress CMS depends upon the installed plugins and modules. It is possible to load them by simply passing the module and plugin names, separated by a comma, to the load-scripts.php file through the “load” parameter. https://your-wordpress-site.com/wp-admin/load-scripts.php?c=1&load[]=eutil,common,wp-a11y,sack,quicktag,colorpicker,editor,wp-fullscreen-stu,wp-ajax-response,wp-api-request,wp-pointer,autosave,heartbeat,wp-auth-check,wp-lists,prototype,scriptaculous-root,scriptaculous-builder,scriptaculous-dragdrop,scriptaculous-effects,scriptaculous-slider,scriptaculous-sound,scriptaculous-controls,scriptaculous The ‘load-scripts.php’ finds the JavaScript files included in the URL and appends their content into a single file and then send back it to the user’s web browser. The researcher highlighted that the wp_scripts list is hard-coded and is defined in the script-loader.php file, so he decided to send a request that in response will get all the JS module of the WordPress instance. “There is a well-defined list ($wp_scripts), that can be requested by users as part of the load[] parameter. If the requested value exists, the server will perform an I/O read action for a well-defined path associated with the supplied value from the user.” “I wondered what would happen if I sent the server a request to supply me every JS module that it stored? A single request would cause the server to perform 181 I/O actions and provide the file contents in the response.” Tawily developed a proof-of-concept (PoC) python script called doser.py that he used to makes large numbers of concurrent requests to the same URL to saturate the resources of the servers. An attacker with a good bandwidth or a limited number of bots can trigger the CVE-2018-6389 vulnerability to target popular WordPress websites. Tawily reported this DoS vulnerability to the WordPress team through HackerOne platform, but the company refused to acknowledge the flaw. “After going back and forth about it a few times and my trying to explain and provide a PoC, they refused to acknowledge it and claimed that: “This kind of thing should really be mitigated at the server or network level rather than the application level, which is outside of WordPress’s control.“” Tawily wrote. The expert has implemented the mitigation against this vulnerability in a forked version of WordPress, he has also released a bash script that addresses the issue. https://securityaffairs.co/wordpress/68709/hacking/cve-2018-6389-wordpress-dos-flaw.html

Yesterday (Monday, February 5, 2018), a zero-day vulnerability in WordPress core was disclosed, which allows an attacker to perform a denial of service (DoS) attack against a vulnerable application. The vulnerability exists in the modules used to load JS and CSS files. These modules were designed to decrease page-loading time, but have effectively rendered the WordPress core susceptible to DoS attacks. WordPress holds a market share of more than 29 percent of internet websites and 60 percent of content management systems (CMS) worldwide, turning any vulnerability in the WordPress core into a potentially large-scale exploit. The vulnerability exists due to a flaw in the server-side static file loading mechanism. The parameter “load” in the vulnerable modules “load-styles.php” and “load-scripts.php”, which reside under the “/wp-admin/” path, accepts an array of JS/CSS files to fetch while the page is loading. The vulnerable modules are usually used only in pages accessible by authenticated users, with an exception being the login page, which exposes said modules to unauthenticated users as well. Thus, a malicious user can repeatedly request an excessive list of JS/CSS files, causing the server to retrieve vast amounts of data — and in so — render it unresponsive. Although the load parameter can accept all 181 JS files that appear in the “script-loader.php” module. Our analysis has shown that, in fact, the server doesn’t retrieve any data when calling JS files that are pulled from an external source such as https://ajax.googleapis.com. Hence, appending these JS files to the requested list is useless from an attacker’s perspective. Due to the simplicity of this attack, a low skill attacker can utilize the existing public exploit to take down virtually any unprotected WordPress site. Because the vulnerable modules are essential, a blacklist isn’t recommended and a simple authentication-based whitelist will not work either because it may break the login page. WordPress did not patch this vulnerability because they view it as an extensive resource exhaustion attack, and as such should be mitigated by a network firewall / web application firewall. This may, of course, change, and WordPress webmasters should (as always) stay tuned for new patches and versions. Until today (February 6, 2018), we have only seen a few dozen exploit attempts using this vulnerability, but we might see a steep rise in attacks using this exploit due to the popularity of the platform, unless a mitigation will be applied in the near future. It is advised to set access restrictions to the “load-styles.php” and “load-scripts.php” modules by only allowing trusted IPs to access these resources or by enabling two-factor authentication on the wp-admin directory. Another solution is to set rate limits to these resources. Vulnerability discoverer Barak Tawily released the following Bash script that patches the exploit by essentially allowing only admins to send requests to the vulnerable modules, and removes the requests to the modules from the login page. The script also removes most of the code from the “noop.php” module due to “re-declaration errors”. In a testing environment in our lab we didn’t encounter any such errors and thus we assume that altering the “noop.php” is not obligatory for all WordPress users. We did not extensively test this patch in our lab, and as of today, it wasn’t integrated into the main WordPress repository. Thus, we cannot recommend this solution, as it deviates from the WordPress core source and may cause compatibility issues. After analyzing the data on our CDN, we have deployed mitigations against this vulnerability, which are enabled by default for all Incapsula sites with protection against “Illegal Resource Access”. https://www.incapsula.com/blog/cve-2018-6389-wordpress-parameter-resource-consumption-remote-dos.html?mkt_tok=eyJpIjoiWkdVNE5UUXhaalUxTUdZMSIsInQiOiJzSEl2RzJvaDZXM0FuWWJ6R1Z2SlNzdUU4OEh0Q0JZcXlhcTYzc0FUbW9hOUFwaFwvMmlmN0Y0bitEREtNUzlwYjk3SWdsOEVtZ2pkQlZ2TFZYTWlwUG1ndWhnaW42K1N6ODdSRFdMZ0YzSzI2eWpEbkhZaVYreWdxMUhKZ0NTakwifQ%3D%3D

βλεπω και παρόμοια projects για Windows 7 - 8.1 https://gist.github.com/xvitaly/eafa75ed2cb79b3bd4e9

I’ve been experimenting with MySQL Fabric – the official tool in development to provide HA and sharding. Part of this experimentation has meant that I have been running 7 copies of the MySQL Server on my laptop at once, which can consume a lot of memory 🙂 So today I wanted to write about how to configure MySQL to use less memory, which may also be beneficial in situations where peak performance is not important. For example: a developer VM environment. Previous configuration guides Before I get started, let me point to some of my previous configuration guides: Reducing MySQL durability for testing environments – losing the ability to recover all changes in exchange for a performance gain. Improving MySQL’s default configuration – explaining the motivation of changing the defaults for MySQL 5.6. What to tune in MySQL 5.6 after installation – explaining what changes to make in production for MySQL 5.6. Configuring MySQL to use minimal memory The MySQL defaults have to balance performance with what is considered reasonable for what may be a development system with other applications needing to run alongside MySQL. In many cases, this will mean 4-8GB, but on virtual machines (or in my case with 7 copies of mysqld running), there is a lot less available. Obligatory warning: If you are running these settings on a machine with 1GB+ RAM, you should expect worse performance when compared to the defaults. Setting Default Minimum innodb_buffer_pool_size 128M 5M innodb_log_buffer_size 1M 256K query_cache_size 1M 0 max_connections 151 1 (although 10 might be more reasonable) key_buffer_size 8388608 8 thread_cache_size (autosized) 0 host_cache_size (autosized) 0 innodb_ft_cache_size 8000000 1600000 innodb_ft_total_cache_size 640000000 32000000 thread_stack 262144 131072 sort_buffer_size 262144 32K read_buffer_size 131072 8200 read_rnd_buffer_size 262144 8200 max_heap_table_size 16777216 16K tmp_table_size 16777216 1K bulk_insert_buffer_size 8388608 0 join_buffer_size 262144 128 net_buffer_length 16384 1K innodb_sort_buffer_size 1M 64K binlog_cache_size 32K 4K binlog_stmt_cache_size 32K 4K (Note: you may be able to save a little more memory by disabling InnoDB or performance schema, but I don’t recommend these two steps.) To summarize these changes: # /etc/my.cnf: innodb_buffer_pool_size=5M innodb_log_buffer_size=256K query_cache_size=0 max_connections=10 key_buffer_size=8 thread_cache_size=0 host_cache_size=0 innodb_ft_cache_size=1600000 innodb_ft_total_cache_size=32000000 # per thread or per operation settings thread_stack=131072 sort_buffer_size=32K read_buffer_size=8200 read_rnd_buffer_size=8200 max_heap_table_size=16K tmp_table_size=1K bulk_insert_buffer_size=0 join_buffer_size=128 net_buffer_length=1K innodb_sort_buffer_size=64K #settings that relate to the binary log (if enabled) binlog_cache_size=4K binlog_stmt_cache_size=4K http://www.tocker.ca/2014/03/10/configuring-mysql-to-use-minimal-memory.html

You can check hardisk performance write/read speed in command line. For list all disk installed on your server use this command ; fdisk -l Sample output : Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 25 200781 83 Linux /dev/sda2 26 1300 10241437+ 83 Linux /dev/sda3 1301 6399 40957717+ 83 Linux /dev/sda4 6400 60801 436984065 5 Extended /dev/sda5 6400 10223 30716248+ 83 Linux /dev/sda6 10224 14047 30716248+ 83 Linux /dev/sda7 14048 16087 16386268+ 82 Linux swap / Solaris /dev/sda8 16088 16724 5116671 83 Linux /dev/sda9 16725 60801 354048471 83 Linux Disk /dev/sdb: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 * 1 60801 488384001 83 Linux In this case we want to check first hard disk /dev/sda, use this command ; hdparm -t /dev/sda ample output : /dev/sda: Timing buffered disk reads: 310 MB in 3.05 seconds = 101.48 MB/sec or you can use dd command ; dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync Sample output : 16384+0 records in 16384+0 records out 1073741824 bytes (1.1 GB) copied, 22.6081 seconds, 47.5 MB/s http://ssh9.com/tips-and-tricks/check-hard-disk-speed-in-centos-from-command-line

CloudFlair is a tool to find origin servers of websites protected by CloudFlare who are publicly exposed and don't restrict network access to the CloudFlare IP ranges as they should. The tool uses Internet-wide scan data from Censys to find exposed IPv4 hosts presenting an SSL certificate associated with the target's domain name. For more detail about this common misconfiguration and how CloudFlair works, refer to the companion blog post at https://blog.christophetd.fr/bypassing-cloudflare-using-internet-wide-scan-data/. Here's what CloudFlair looks like in action. $ python cloudflair.py myvulnerable.site [*] The target appears to be behind CloudFlare. [*] Looking for certificates matching "myvulnerable.site" using Censys [*] 75 certificates matching "myvulnerable.site" found. [*] Looking for IPv4 hosts presenting these certificates... [*] 10 IPv4 hosts presenting a certificate issued to "myvulnerable.site" were found. - 51.194.77.1 - 223.172.21.75 - 18.136.111.24 - 127.200.220.231 - 177.67.208.72 - 137.67.239.174 - 182.102.141.194 - 8.154.231.164 - 37.184.84.44 - 78.25.205.83 [*] Retrieving target homepage at https://myvulnerable.site [*] Testing candidate origin servers - 51.194.77.1 - 223.172.21.75 - 18.136.111.24 responded with an unexpected HTTP status code 404 - 127.200.220.231 timed out after 3 seconds - 177.67.208.72 - 137.67.239.174 - 182.102.141.194 - 8.154.231.164 - 37.184.84.44 - 78.25.205.83 [*] Found 2 likely origin servers of myvulnerable.site! - 177.67.208.72 (HTML content identical to myvulnerable.site) - 182.102.141.194 (HTML content identical to myvulnerable.site) (The IP addresses in this example have been obfuscated and replaced by randomly generated IPs) Setup Register an account (free) on https://censys.io/register Browse to https://censys.io/account/api, and set two environment variables with your API ID and API secret $ export CENSYS_API_ID=... $ export CENSYS_API_SECRET=... Clone the repository $ git clone https://github.com/christophetd/cloudflair.git Install the dependencies $ cd cloudflair $ pip install -r requirements.txt Run CloudFlair (see Usage below for more detail) $ python cloudflair.py myvulnerable.site Usage $ python cloudflair.py --help usage: cloudflair.py [-h] [-o OUTPUT_FILE] [--censys-api-id CENSYS_API_ID] [--censys-api-secret CENSYS_API_SECRET] domain positional arguments: domain The domain to scan optional arguments: -h, --help show this help message and exit -o OUTPUT_FILE, --output OUTPUT_FILE A file to output likely origin servers to (default: None) --censys-api-id CENSYS_API_ID Censys API ID. Can also be defined using the CENSYS_API_ID environment variable (default: None) --censys-api-secret CENSYS_API_SECRET Censys API secret. Can also be defined using the CENSYS_API_SECRET environment variable (default: None) Compatibility Tested on Python 2.7 and 3.5. Feel free to open an issue if you have bug reports or questions. https://github.com/christophetd/CloudFlair

This tutorial REPLACES PHP 5.X COMPLETELY. Do NOT use it if you want multiple PHP versions. If you have REMI Repository you can skip this step. wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm wget http://rpms.remirepo.net/enterprise/remi-release-7.rpm rpm -Uvh remi-release-7.rpm epel-release-latest-7.noarch.rpm Then enable Remi yum --enablerepo=remi update remi-release Now remove old PHP and install PHP7 service php-fpm stop yum -y --enablerepo=remi install php70-php php70-php-pear php70-php-bcmath php70-php-pecl-jsond-devel php70-php-mysqlnd php70-php-gd php70-php-common php70-php-fpm php70-php-intl php70-php-cli php70-php php70-php-xml php70-php-opcache php70-php-pecl-apcu php70-php-pecl-jsond php70-php-pdo php70-php-gmp php70-php-process php70-php-pecl-imagick php70-php-devel php70-php-mbstring Remove and re-link new PHP7 rm -f /usr/bin/php ln -s /usr/bin/php70 /usr/bin/php Test if we have PHP 7 php -v Output should be (take note of PHP 7!!) [root@tiny system]# php -v PHP 7.0.9 (cli) (built: Jul 20 2016 16:58:48) ( NTS ) Copyright (c) 1997-2016 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies with Zend OPcache v7.0.9, Copyright (c) 1999-2016, by Zend Technologies Now open up new PHP-FPM.conf ( /etc/opt/remi/php70/php-fpm.conf ) file and change line 11 to: include=/etc/php-fpm.d/*.conf Start PHP-FPM service php70-php-fpm start Remove old systemctl php-fpm and link to new one rm -f /usr/lib/systemd/system/php-fpm.service ln -s /usr/lib/systemd/system/php70-php-fpm.service /usr/lib/systemd/system/php-fpm.service Reload systemctl daemon systemctl daemon-reload Restart web service (i use nginx) service nginx restart https://forum.vestacp.com/viewtopic.php?t=12319

had similar issues on 7.4 but fixed

Loaded plugins: fastestmirror C7.0.1406-base | 3.6 kB 00:00:00 C7.0.1406-updates | 2.9 kB 00:00:00 C7.1.1503-base | 3.6 kB 00:00:00 C7.1.1503-updates | 3.4 kB 00:00:00 C7.2.1511-base | 3.6 kB 00:00:00 C7.2.1511-updates | 3.4 kB 00:00:00 http://vault.centos.org/7.3.1611/os/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 – Not Found Trying other mirror. To address this issue please refer to the below knowledge base article https://access.redhat.com/articles/1320623 If above article doesn’t help to resolve this issue please create a bug on https://bugs.centos.org/ One of the configured repositories failed (CentOS-7.3.1611 – Base), and yum doesn’t have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work “fix” this: 1. Contact the upstream for the repository and get them to fix the problem. 2. Reconfigure the baseurl/etc. for the repository, to point to a working upstream. This is most often useful if you are using a newer distribution release than is supported by the repository (and the packages for the previous distribution release still work). 3. Run the command with the repository temporarily disabled yum –disablerepo=C7.3.1611-base … 4. Disable the repository permanently, so yum won’t use it by default. Yum will then just ignore the repository until you permanently enable it again or use –enablerepo for temporary usage: yum-config-manager –disable C7.3.1611-base or subscription-manager repos –disable=C7.3.1611-base 5. Configure the failing repository to be skipped, if it is unavailable. Note that yum will try to contact the repo. when it runs most commands, so will have to try and fail each time (and thus. yum will be be much slower). If it is a very temporary problem though, this is often a nice compromise: yum-config-manager –save –setopt=C7.3.1611-base.skip_if_unavailable=true failure: repodata/repomd.xml from C7.3.1611-base: [Errno 256] No more mirrors to try. http://vault.centos.org/7.3.1611/os/x86_64/repodata/repomd.xml: [Errno 14] HTTP Error 404 – Not Found Error: yum install failed ———- fix add lines skip_if_unavailable = 1 keepcache = 0 to file /etc/yum.repos.d/CentOS-Vault.repo example: was: [C7.3.1611-extras] name=CentOS-7.3.1611 – Extras baseurl=http://vault.centos.org/7.3.1611/extras/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled=0 now: [C7.3.1611-extras] name=CentOS-7.3.1611 – Extras baseurl=http://vault.centos.org/7.3.1611/extras/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled=0 skip_if_unavailable = 1 keepcache = 0

4.2.7 is a maintenance release that fixes issues identified in 4.2.6 and also adds settings to help with GDPR compliance. This release also contains several security updates. Also included: 4.2.6 This is a maintenance release to fix reported bugs. Other changes include: RSS feeds now use guest page caching system Analytic tracking code has been moved to inside head tag Ad code placement has a new setting to clarify how sidebar display should be handled Various enhancements to Redis engine including data stored encrypted at rest Search result improvements

How to check Linux for Spectre and Meltdown vulnerability Posted onJanuary 8, 2018in CategoriesCentOS, Debian / Ubuntu, Linux, RedHat and Friends,Security, Suse last updated January 8, 2018 How do I check if my Linux server is still vulnerable to Spectre and Meltdown CPU bugs? Spectre & Meltdown Checker is a shell script that check for the following Intel/AMD/ARM and other CPUs for bugs: CVE-2017-5753: bounds check bypass (Spectre Variant 1). You need to recompile software and kernel with a modified compiler that introduces the LFENCE opcode at the proper positions in the resulting code. The performance impact of the mitigation is negligible. CVE-2017-5715: branch target injection (Spectre Variant 2). The performance impact of the mitigation depending on your CPU. CVE-2017-5754: rogue data cache load (Meltdown). You must install updated kernel version with PTI/KPTI patches. Updating the kernel is enough. The performance impact of the mitigation is low to medium. spectre-meltdown-checker.sh is a simple shell script to find out if your Linux kernel (installation) is vulnerable against the 3 “speculative execution” CVEs. Use this script to check or see if you are still vulnerable to Meltdown and Spectre CPU bugs after applying kernel patches. Installation The script must be run as root user. You can view source code here. Use the wget command or curl command to grab the source code on your Linux box: $ cd /tmp/ $ wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh OR $ git clone https://github.com/speed47/spectre-meltdown-checker.git Sample outputs: Cloning into 'spectre-meltdown-checker'... remote: Counting objects: 155, done. remote: Compressing objects: 100% (20/20), done. remote: Total 155 (delta 18), reused 21 (delta 10), pack-reused 125 Receiving objects: 100% (155/155), 49.78 KiB | 145.00 KiB/s, done. Resolving deltas: 100% (88/88), done. How to check Linux for Spectre and Meltdown vulnerability Run the script as root user using sudo command or su command: $ sudo sh spectre-meltdown-checker.sh Sample outputs from Ubuntu Linux desktop: [sudo] password for vivek: Spectre and Meltdown mitigation detection tool v0.16 Checking vulnerabilities against Linux 4.13.0-21-generic #24-Ubuntu SMP Mon Dec 18 17:29:16 UTC 2017 x86_64 CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Kernel compiled with LFENCE opcode inserted at the proper places: NO (only 42 opcodes found, should be >= 70) > STATUS: VULNERABLE CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigation 1 * Hardware (CPU microcode) support for mitigation: NO * Kernel support for IBRS: NO * IBRS enabled for Kernel space: NO * IBRS enabled for User space: NO * Mitigation 2 * Kernel compiled with retpoline option: NO * Kernel compiled with a retpoline-aware compiler: NO > STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Kernel supports Page Table Isolation (PTI): NO * PTI enabled and active: NO > STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability) Another output from my CentOS 7.x server where Meltdown/Spectre v1 was patched with Kernel: $ sudo sh spectre-meltdown-checker.sh Spectre Meltdown vulnerability mitigation detection check tool for Linux (click to enlarge) For more info see the official github page here. https://www.cyberciti.biz/faq/check-linux-server-for-spectre-meltdown-vulnerability/

http://www.zdnet.com/article/intel-starts-issuing-patches-for-meltdown-spectre-vulnerabilities/ Intel on Thursday began issuing patches for the Meltdown and Spectre vulnerabilities linked to its processors. In a press release, the Santa Clara-based tech giant said it has "developed and is rapidly issuing updates for all types of Intel-based computer systems -- including personal computers and servers -- that render those systems immune from both exploits reported by Google Project Zero." The two critical chip vulnerabilities date back more than two decades and were found to enable an attacker to steal data from the memory of running apps, such as data from password managers, browsers, emails, and photos and documents. The researchers who discovered the vulnerabilities said that "almost every system," since 1995, including computers and phones, is affected by the bug. Intel says it has already issued updates for the majority of its processor products released in the last five years. By the end of next week, the company expects to have updates for 90 percent of the past five years' processors. Additionally, Intel said that "many operating system vendors, public cloud service providers, device manufacturers and others have indicated that they have already updated their products and services." It's still unclear when Intel will have patches ready for processors that are more than five years old. Intel maintains that there are no known exploits for the vulnerabilities, but it's encouraging computer users worldwide to enable automatic updates of their operating systems and other computer software to keep their systems up-to-date.

Huge Flaws Affect Nearly Every Modern Device; Patch Could Hit CPU Performance Wednesday, January 03, 2018 Swati Khandelwal UPDATE: Researchers have finally disclosed complete technical details of two kernel side-channel attacks, Meltdown and Spectre—which affect not only Intel but also systems and devices running AMD, ARM processors—allowing attackers to steal sensitive data from the system memory. ____________ The first week of the new year has not yet been completed, and very soon a massive vulnerability is going to hit hundreds of millions of Windows, Linux, and Mac users worldwide. According to a blog post published yesterday, the core team of Linux kernel development has prepared a critical kernel update without releasing much information about the vulnerability. Multiple researchers on Twitter confirmed that Intel processors (x86-64) have a severe hardware-level issue that could allow attackers to access protected kernel memory, which primarily includes information like passwords, login keys, and files cached from disk. The security patch implements kernel page-table isolation (KPTI) to move the kernel into an entirely separate address space and keeps it protected and inaccessible from running programs and userspace, which requires an update at the operating system level. "The purpose of the series is conceptually simple: to prevent a variety of attacks by unmapping as much of the Linux kernel from the process page table while the process is running in user space, greatly hindering attempts to identify kernel virtual address ranges from unprivileged userspace code," writes Python Sweetness. It is noteworthy that installing the update will hit your system speed negatively and could bring down CPUs performance by 5 percent to 30 percent, "depending on the task and processor model." "With the page table splitting patches merged, it becomes necessary for the kernel to flush these caches every time the kernel begins executing, and every time user code resumes executing." Much details of the flaw have been kept under wraps for now, but considering its secrecy, some researchers have also speculated that a Javascript program running in a web browser can recover sensitive kernel-protected data. AMD processors are not affected by the vulnerability due to security protections that the company has in place, said Tom Lendacky, a member of the Linux OS group at AMD. "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against," the company said. "The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault." The Linux patch that is being released for ALL x86 processors also includes AMD processors, which has also been considered insecure by the Linux mainline kernel, but AMD recommends specifically not to enable the patch for Linux. Microsoft is likely to fix the issue for its Windows operating system in an upcoming Patch Tuesday, and Apple is also likely working on a patch to address the vulnerability. https://thehackernews.com/2018/01/intel-kernel-vulnerability.html

https://meltdownattack.com/ Meltdown and Spectre Bugs in modern computers leak passwords and sensitive data. Meltdown and Spectre exploit critical vulnerabilities in modern processors. These hardware bugs allow programs to steal data which is currently processed on the computer. While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs. This might include your passwords stored in a password manager or browser, your personal photos, emails, instant messages and even business-critical documents. Meltdown and Spectre work on personal computers, mobile devices, and in the cloud. Depending on the cloud provider's infrastructure, it might be possible to steal data from other customers. Meltdown Meltdown breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system. If your computer has a vulnerable processor and runs an unpatched operating system, it is not safe to work with sensitive information without the chance of leaking the information. This applies both to personal computers as well as cloud infrastructure. Luckily, there are software patches against Meltdown. Spectre Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre Spectre is harder to exploit than Meltdown, but it is also harder to mitigate. However, it is possible to prevent specific known exploits based on Spectre through software patches.

https://googleprojectzero.blogspot.gr/2018/01/reading-privileged-memory-with-side.html Tested Processors Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (called "Intel Haswell Xeon CPU" in the rest of this document) AMD FX(tm)-8320 Eight-Core Processor (called "AMD FX CPU" in the rest of this document) AMD PRO A8-9600 R7, 10 COMPUTE CORES 4C+6G (called "AMD PRO CPU" in the rest of this document) An ARM Cortex A57 core of a Google Nexus 5x phone [6] (called "ARM Cortex A57" in the rest of this document)

Red Hat has been made aware of multiple microarchitectural (hardware) implementation issues affecting many modern microprocessors, requiring updates to the Linux kernel, virtualization-related components, and/or in combination with a microcode update. An unprivileged attacker can use these flaws to bypass conventional memory security restrictions in order to gain read access to privileged memory that would otherwise be inaccessible. There are 3 known CVEs related to this issue in combination with Intel, AMD, and ARM architectures. Additional exploits for other architectures are also known to exist. These include IBM System Z, POWER8 (Big Endian and Little Endian), and POWER9 (Little Endian). Background Information An industry-wide issue was found with the manner in which many modern microprocessor designs have implemented speculative execution of instructions (a commonly used performance optimization). There are three primary variants of the issue which differ in the way the speculative execution can be exploited. All three rely upon the fact that modern high performance microprocessors implement both speculative execution, and utilize VIPT (Virtually Indexed, Physically Tagged) level 1 data caches that may become allocated with data in the kernel virtual address space during such speculation. The first two variants abuse speculative execution to perform bounds-check bypass (CVE-2017-5753), or by utilizing branch target injection (CVE-2017-5715) to cause kernel code at an address under attacker control to execute speculatively. Collectively these are known as "Spectre". Both variants rely upon the presence of a precisely-defined instruction sequence in the privileged code, as well as the fact that memory accesses may cause allocation into the microprocessor’s level 1 data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use these two flaws to read privileged memory by conducting targeted cache side-channel attacks. These variants could be used not only to cross syscall boundary (variant 1 and variant 2) but also guest/host boundary (variant 2). The third variant (CVE-2017-5754) relies on the fact that, on impacted microprocessors, during speculative execution of instruction permission faults, exception generation triggered by a faulting access is suppressed until the retirement of the whole instruction block. Researchers have called this exploit "Meltdown". Subsequent memory accesses may cause an allocation into the L1 data cache even when they reference otherwise inaccessible memory locations. As a result, an unprivileged local attacker could read privileged (kernel space) memory (including arbitrary physical memory locations on a host) by conducting targeted cache side-channel attacks. https://access.redhat.com/security/vulnerabilities/speculativeexecution?sc_cid=701f2000000tsLNAAY&

A critical security vulnerability has been reported in phpMyAdmin—one of the most popular applications for managing the MySQL database—which could allow remote attackers to perform dangerous database operations just by tricking administrators into clicking a link. Discovered by an Indian security researcher, Ashutosh Barot, the vulnerability is a cross-site request forgery (CSRF) attack and affects phpMyAdmin versions 4.7.x (prior to 4.7.7). Cross-site request forgery vulnerability, also known as XSRF, is an attack wherein an attacker tricks an authenticated user into executing an unwanted action. According to an advisory released by phpMyAdmin, "by deceiving a user to click on a crafted URL, it is possible to perform harmful database operations such as deleting records, dropping/truncating tables, etc." phpMyAdmin is a free and open source administration tool for MySQL and MariaDB and is widely used to manage the database for websites created with WordPress, Joomla, and many other content management platforms. Moreover, a lot of hosting providers use phpMyAdmin to offer their customers a convenient way to organize their databases. Barot has also released a video, as shown above, demonstrating how a remote attacker can make database admins unknowingly delete (DROP) an entire table from the database just by tricking them into clicking a specially crafted link. "A feature of phpMyAdmin was using a GET request and after that POST request for Database operations such as DROP TABLE table_name; GET requests must be protected against CSRF attacks. In this case, POST requests were used which were sent through URL (for bookmarking purpose may be); it was possible for an attacker to trick a database admin into clicking a button and perform a drop table database query of the attacker’s choice." Barot explains in a blog post. However, performing this attack is not simple as it may sound. To prepare a CSRF attack URL, the attacker should be aware of the name of targeted database and table. "If a user executes a query on the database by clicking insert, DROP, etc. buttons, the URL will contain database name and table name," Barot says. "This vulnerability can result in the disclosure of sensitive information as the URL is stored at various places such as browser history, SIEM logs, Firewall Logs, ISP Logs, etc." Barot reported the vulnerability to phpMyAdmin developers, who confirmed his finding and released phpMyAdmin 4.7.7 to address this issue. So administrators are highly recommended to update their installations as soon as possible. https://thehackernews.com/2018/01/phpmyadmin-hack.html

Hi, I wrote this script in order to add a line to root crontab if it does not already contain such line. The script also checks if the crontab is empty. Is there a better way to achieve this? Code: cronList=$(sudo crontab -u root -l) if [ $(echo $cronList | grep -c "@weekly /home/user/command") -eq 0 ]; then if [ -z "$cronList" ]; then echo "@weekly /home/user/command" | sudo crontab -u root - else (sudo crontab -u root -l; echo "@weekly /home/user/command" ) | sudo crontab -u root - fi fi Thank you https://ubuntuforums.org/showthread.php?t=2315654

@reboot sleep 600; find ${HOME}/my_app/check_conn.rb https://askubuntu.com/questions/490881/run-the-script-file-after-5-or-10-min-after-restarting-the-system

nice ideas @reboot sleep 60 && my_script.sh or @reboot echo /root/bin/do_the_stuff | at now + 2 minutes # at assigns it an execution time truncated to whole minutes, # so this means it will execute in 1--2 minutes. https://unix.stackexchange.com/questions/57852/crontab-job-start-1-min-after-reboot

http://www.shopdeluxe.fr/check_ps/index.php

http://runprestashop.com/ Does Website X Run Prestashop?

How to configure PrestaShop to work with another domain PrestaShop, like many other applications out there is domain name dependent. In case you wish to use your PrestaShop with a different domain name you should follow the instructions below: For PrestaShop 1.4.x or the older versions: Access phpMyAdmin in cPanel and navigate to your PrestaShop database. Select the configuration table (e.g. ps_configuration) and find the PS_SHOP_DOMAIN and PS_SHOP_DOMAIN_SSL records. Change their values to match your new domain name. You should also make sure that your PrestaShop's base directory is correctly set in the application's configuration file located under /config/settings.inc.php. You can edit the configuration file via FTP, or File Manager in cPanel. Once you have opened the file for editing look for the line: define('__PS_BASE_URI__', '/'); In case your PrestaShop installation is located in the web root folder of your domain name, this line should remain as above. If the installation is located into a sub folder, the line should be changed to reflect its location: define('__PS_BASE_URI__', '/subfolder/'); Where subfolder is the actual name of the folder where PrestaShop is installed. For PrestaShop 1.5.x: The only thing that you need to do is to change the shop URL from the database of your application. In order to do that you will need to: Log into cPanel and access phpMyAdmin. Locate the table shop_url and change the values for the records: domain and domain_ssl to your new domain name. Then change the value of the record physical_url in the same table. If you have installed the PrestaShop directly in the domain's document root, you will need to change the physical_url to " / ". If Prestashop is installed in a sub folder, the value of physical_url should be the sub folder's name. Example: For PrestaShop installed in http://yourdomain.com/subfolder the records should be: domain = yourdomain.com domain_ssl = yourdomain.com physical_url = /subfolder/ For PrestaShop 1.6.x/1.7.x: Log into cPanel and go to phpMyAdmin. Navigate to your PrestaShop database and open the configuration table (e.g. ps_configuration). Find the PS_SHOP_DOMAIN and PS_SHOP_DOMAIN_SSL records and change their values to match your new domain name. Then open the shop_url table (e.g. ps_shop_url) and change the domain, domain_ssl and physical_uri columns to match the new location of the application. Remove all the files inside the folders cache/smarty/compile/ and cache/smarty/cache/, except the index.php files situated there. You can do that easily via FTP. Log into your PrestaShop admin panel on new domain and verify if everything is working properly - browse through all pages, products, images and themes, etc. In case you need to modify the MySQL database details of your PrestaShop you can do that in the following database configuration files located in the root folder of your PrestaShop installation: PrestaShop 1.4.x/1.5.x/1.6.x - config/settings.inc.php PrestaShop 1.7.x - app/config/parameters.php