firewalld-0.4.4.2-1.fc23

– New firewalld-selinux sub package delivering the SELinux policy module for
firewalld (RHBZ#1396765) (RHBZ#1394625) (RHBZ#1394578) (RHBZ#1394573)
(RHBZ#1394569)
– New firewalld release 0.4.4.2:
– firewalld.spec: Added helpers and ipsets paths to firewalld-filesystem
– firewall.core.fw_nm: create NMClient lazily
– Do not use hard-coded path for modinfo, use autofoo to detect it
– firewall.core.io.ifcfg: Dropped invalid option warning with bad format
string
– firewall.core.io.ifcfg: Properly handle quoted ifcfg values
– firewall.core.fw_zone: Do not reset ZONE with ifdown
– Updated translations from zanata
– firewall-config: Extra grid at bottom to visualize firewalld settings

—-

**Support Recognition of Automatic Helper Assignment Setting**

Automatic helper assignment has been disabled in kernel 4.7. firewalld version 0.4.4 is now able to recognize this and to create rules if automatic helper assignment has been turned off to make conntrack helpers work again. If automatic helper assignment is turned on, then firewalld will behave as before.

For more information about the use of netfilter conntrack helper, please have a look at http://www.firewalld.org/2016/10/automatic-helper-assignment

**Firewall-applet is now using Qt5**

The firewall applet has been ported from Qt4 to Qt5.

**Fixes LogDenied for zone reject targets**

The logging rules for LogDenied have been placed after the reject rules for zones using the reject targets. The logging rules are now placed before these reject rules to fix logging.

**Does not abort transaction on failed ipv6_rpfilter rules**

The existing transaction will be executed before trying to add the rules for ipv6_rpfilter and a new transaction will be used to apply the ipv6_rpfiler rules. If this transaction fails, a warning is printed out and the remaining rules are applied with the next transaction.

**Enhancements for the command line tools**

The command line tools are now more consistent with errors and error codes in sequence options. The NOT_AUTHORIZED error is now also working.

**New services**

The services cfengine, condor-collector and smtp-submission have been added.

**firewall-config: Use proper source check in sourceDialog (issue #162)**

**firewallctl: Use sys.excepthook to force exception_handler usage always**

**firewallctl: Support helpers**

**Several other enhancements and fixes**

—-

– Fix CVE-2016-5410: Firewall configuration can be modified by any logged in user
– firewall/server/firewalld: Make getXSettings and getLogDenied CONFIG_INFO
– Update AppData configuration file.
– tests/firewalld_rich.py: Use new import structure and FirewallClient classes
– tests/firewalld_direct.py: Use new import structure
– tests: firewalld_direct: Fix assert to check for True instead of False
– tests: firewalld_config: Fix expected value when querying the zone target
– tests: firewalld_config: Use real nf_conntrack modules
– firewalld.spec: Added comment about make call for %build
– firewall-config: Use also width_request and height_request with default size
– Updated firewall-config screenshot
– firewall-cmd: Fixed typo in help output (RHBZ#1367171)
– test-suite: Ignore stderr to get default zone also for missing firewalld.conf
– firewall.core.logger: Warnings should be printed to stderr per default
– firewall.core.fw_nm: Ignore NetworkManager if NM.Client connect fails
– firewall-cmd, firewallctl: Gracefully fail if SystemBus can not be aquired
– firewall.client: Generate new DBUS_ERROR if SystemBus can not be aquired
– test-suite: Do not fail on ALREADY_ENABLED –add-destination tests
– firewall.command: ALREADY_ENABLED, NOT_ENABLED, ZONE_ALREADY_SET are warnings
– doc/xml/firewalld.dbus.xml: Removed undefined reference
– doc/xml/transform-html.xsl.in: Fixed references in the document
– doc/xml/firewalld.{dbus,zone}.xml: Embed programlisting in para
– doc/xml/transform-html.xsl.in: Enhanced html formatting closer to the man page
– firewall: core: fw_nm: Instantiate the NM client only once
– firewall/core/io/*.py: Do not traceback on a general sax parsing issue
– firewall-offline-cmd: Fix –{add,remove}-entries-from-file
– firewall-cmd: Add missing action to fix –{add,remove}-entries-from-file
– firewall.core.prog: Do not output stderr, but return it in the error case
– firewall.core.io.ifcfg.py: Fix ifcfg file reader and writer (RHBZ#1362171)
– config/firewall.service.in: use KillMode=mixed
– config/firewalld.service.in: use network-pre.target
– firewall-config: Add missing gettext.textdomain call to fix translations
– Add UDP to transmission-client.xml service
– tests/firewall-[offline-]cmd_test.sh: Hide errors and warnings
– firewall.client: Fix ALREADY_ENABLED errors in icmptype destination calls
– firewall.client: Fix NOT_ENABLED errors in icmptype destination calls
– firewall.client: Use {ALREADY,NOT}_ENABLED errors in icmptype destination
calls
– firewall.command: Add the removed FirewallError handling to the action
(a17ce50)
– firewall.command: Do not use query methods for sequences and also single
options
– Add missing information about MAC and ipset sources to man pages and help
output
– firewalld.spec: Add BuildRequires for libxslt to enable rebuild of man pages
– firewall[-offline]-cmd, firewallctl, firewall.command: Use sys.{stdout,stderr}
– firewallctl: Fix traceback if not connected to firewalld
– firewall-config: Initialize value in on_richRuleDialogElementChooser_clicked
– firewall.command: Convert errors to string for Python3
– firewall.command: Get proper firewall error code from D-BusExceptions
– firewall-cmd: Fixed traceback without args
– Add missing service files to Makefile.am
– shell-completion: Add shell completion support for
–{get,set}–{description,short}

Apple iOS v10.1 & 10.1.1 – iCloud & Device Lock Bypass on Activate via local Buffer Overflow Vulnerability (Wifi Network)

Posted by Vulnerability Lab on Dec 01

Title: Apple iOS v10.1 & 10.1.1 – iCloud & Device Lock Bypass on
Activate via local Buffer Overflow Vulnerability (Wifi Network)

URL: https://www.youtube.com/watch?v=yygvBJBFy4s

Ref: https://www.vulnerability-lab.com/get_content.php?id=2018

Note: Using the rotate function and night shift to merge the mask,
allows as well to bypass the protection for iOS v10.1.1 like in the
video demonstrated.

Your Tinder Account could be hacked.

Security researchers have discovered that two of the world’s most popular mobile dating apps can be hacked, exposing sensitive user data in the process. The team from the University of South Australia ran a series of tests, proving that a number of personal details could be extracted from the apps relatively easily.

Capturing network traffic reveals all

The two apps in question, Tinder and Grindr, claim to keep personal details private until users select a match, someone they want to make.

The two apps in question, Tinder and Grindr, claim to keep personal details private until users select a match, someone they want to make contact with. It is only at this point email addresses or usernames are shared, allowing people to connect directly.

The team of experts found that a determined hacker could capture information as it passed between the user’s phone and the Internet. Flaws in the apps themselves could also be exploited to reveal even more information directly on the Android smartphone.

Using the same techniques demonstrated by the university team on the Tinder app, hackers are able to recover all the profile images viewed by the user, along with details of each “match”. Further probing reveals the user’s unique Facebook token – a string of numbers and letters that could be used to personally identify the app user.

Security tests suggest that Grindr is even less secure. Among the information recovered were the details of profiles the user had viewed, along with their own email address. Even more worrying was the discovery that messages from private chats could also be accessed by hackers.

Why does it matter?

Romantic relationships are built on trust by sharing private thoughts and feelings with another person. We make ourselves vulnerable by discussing things we wouldn’t share anywhere else.

This kind of deeply personal information is extremely attractive to hackers who can use it to blackmail the user, or to build a personal profile for advanced social engineering attacks. The secrets revealed in private conversations can often be used to guess passwords, or “trick” people into handing over valuable information like bank account numbers.

How to protect Tinder against hacking

Tinder and Grindr were both criticized by the University of South Australia for failing to properly protect users’ data. In the conclusion of their report, users were urged to be extra careful about the apps they install on their Android phones.

Ultimately the responsibility for these problems lie with the app developers who need to improve their security provisions. In the meantime, Android users can enhance their own protection using Panda Mobile Security to prevent personal data from being accessed without permission – as was the case here.

Panda Mobile Security prevents malicious apps from stealing data, and can be configured to limit data sharing between legitimate apps, helping to keep your sensitive personal information away from hackers. Which means you can focus on finding love without someone accessing your private chats.

The post Your Tinder Account could be hacked. appeared first on Panda Security Mediacenter.