You are not logged in.
- Topics: Active | Unanswered
#1 Re: Off-topic » CVE-2024-6387: RCE in OpenSSH's server, on glibc-based Linux systems » 2024-07-06 14:16:22
Hate asking, but did you run apt update first? Debian's armhf version is at the correct version.
#2 Re: Off-topic » KeepassXC » 2024-07-02 14:28:04
Does anyone have a list of the features that were omitted re: this bug ticket? One of the commenters mentions it's the "fourth" bug ticket related to feature-removal.
Edit: Unrelated to the question but I found this... https://news.ycombinator.com/item?id=40320166
All they did was change the XC_ALL build parameter to OFF [0] which happens to be the default in upstream's CMakeLists.txt
And
INSTALL.md [0] recommends passing -DWITH_XC_ALL in the Build Steps section.
From Soren's GH issue, it sounds like the maintainers may remove such functionality in the future. https://github.com/keepassxreboot/keepa … 2104750715
As @droidmonkey said, none of these features are plugins. All of them are built-in functionality that belong to the main product. If anything, we will reduce the number of such compile-time flags in the future, so these things cannot be disabled anymore.
I'm not gonna take a position on this since all of this boils down to "free labor" from all parties. The "drive-by contributor attack" is certainly a valid concern these days, notably with respect to the XZ/LZMA fiasco. This could be an interesting case to investigate...
Edit: The Debian packages site isn't loading for me, but my search engine is fetching results for keypasscx-full and keypassxc-minimal. So...
#3 Re: Off-topic » CVE-2024-6387: RCE in OpenSSH's server, on glibc-based Linux systems » 2024-07-01 19:01:48
Upgrade: openssh-client:amd64 (1:9.2p1-2+deb12u2, 1:9.2p1-2+deb12u3)
Now that you mention that, it looks like they released two fixes today: one to address the CVE in the server, and one to fix a separate issue in the client. https://www.openssh.com/releasenotes.html
#4 Off-topic » CVE-2024-6387: RCE in OpenSSH's server, on glibc-based Linux systems » 2024-07-01 16:06:15
- siva
- Replies: 6
Qualys writeup: https://www.qualys.com/2024/07/01/cve-2 … stract.com
Debian security tracker: https://security-tracker.debian.org/tra … -2024-6387
NIST report: https://nvd.nist.gov/vuln/detail/CVE-2024-6387
The Qualys writeup includes an in-depth walkthrough of the vulnerability. Can't find a standalone proof-of-concept at this time.
We discovered a vulnerability (a signal handler race condition) in
OpenSSH's server (sshd): if a client does not authenticate within
LoginGraceTime seconds (120 by default, 600 in old OpenSSH versions),
then sshd's SIGALRM handler is called asynchronously, but this signal
handler calls various functions that are not async-signal-safe (for
example, syslog()). This race condition affects sshd in its default
configuration.On investigation, we realized that this vulnerability is in fact a
regression of CVE-2006-5051 ("Signal handler race condition in OpenSSH
before 4.4 allows remote attackers to cause a denial of service (crash),
and possibly execute arbitrary code"), which was reported in 2006 by
Mark Dowd.This regression was introduced in October 2020 (OpenSSH 8.5p1) by commit
752250c ("revised log infrastructure for OpenSSH"), which accidentally
removed an "#ifdef DO_LOG_SAFE_IN_SIGHAND" from sigdie(), a function
that is directly called by sshd's SIGALRM handler. In other words:- OpenSSH < 4.4p1 is vulnerable to this signal handler race condition,
if not backport-patched against CVE-2006-5051, or not patched against
CVE-2008-4109, which was an incorrect fix for CVE-2006-5051;- 4.4p1 <= OpenSSH < 8.5p1 is not vulnerable to this signal handler race
condition (because the "#ifdef DO_LOG_SAFE_IN_SIGHAND" that was added
to sigdie() by the patch for CVE-2006-5051 transformed this unsafe
function into a safe _exit(1) call);- 8.5p1 <= OpenSSH < 9.8p1 is vulnerable again to this signal handler
race condition (because the "#ifdef DO_LOG_SAFE_IN_SIGHAND" was
accidentally removed from sigdie()).
#5 Re: Off-topic » CVE-2024-3094: LZMA/XZ security report » 2024-04-02 14:55:33
My references weren't related directly to Devuan but I get your point.
#6 Off-topic » CVE-2024-3094: LZMA/XZ security report » 2024-03-31 23:04:42
- siva
- Replies: 3
Thought the group might find this interesting.
From Red Hat:
Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0. Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file existing in the source code, which is then used to modify specific functions in the liblzma code. This results in a modified liblzma library that can be used by any software linked against this library, intercepting and modifying the data interaction with this library.
Related:
- https://gynvael.coldwind.pl/?lang=en&id=782
- https://www.openwall.com/lists/oss-secu … 24/03/29/4
- https://nvd.nist.gov/vuln/detail/CVE-2024-3094
#7 Re: Off-topic » Questions about ARM » 2024-03-15 13:32:43
https://developer.arm.com/documentation … ting-Linux
When the kernel is present in memory, the sequence on an ARM processor based system is similar to what might happen on a desktop computer. However, the bootloading process can be very different, as ARM processor based phones or more deeply embedded devices can lack a hard drive or PC-like BIOS.
Typically, what happens when you power the system on is that hardware specific boot code runs from flash or ROM. This code initializes the system, including any necessary hardware peripheral code and then launches the bootloader (for example U-Boot). This initializes main memory and copies the compressed Linux kernel image into main memory (from a flash device, memory on a board, MMC, host PC or elsewhere). The bootloader passes certain initialization parameters to the kernel. The Linux kernel then decompresses itself and initializes its data structures and running user processes, before starting the command shell environment. Let's take a more detailed look at each of those processes.
Maybe you could adjust your bootloader settings to achieve whatever goal you're looking for?
Also a good thread: https://www.reddit.com/r/arm/comments/9 … nd_a_bios/
You might also enjoy this book: https://www.wiley.com/en-us/Blue+Fox%3A … 1119745303
#8 Re: Off-topic » What are you reading/want to read ? » 2024-03-03 02:12:55
@GlennW: Highly recommend HackTheBox.
#10 Off-topic » GCC 14 Notes » 2024-02-22 01:09:56
- siva
- Replies: 0
Changes, Features, Fixes: https://gcc.gnu.org/gcc-14/changes.html
Porting to GCC 14: https://gcc.gnu.org/gcc-14/porting_to.html
#11 Re: Installation » [SOLVED] Qemu networking client to host fails » 2024-01-03 20:02:11
Yeah their official wiki is pretty straightforward. Glad everything worked out.
#12 Re: Installation » [SOLVED] Qemu networking client to host fails » 2024-01-03 16:01:15
Can you post any logs or error messages related to this issue?
From your POV, what exactly happens when you try to run that command?
Edit:
- Semi-related but you might also want to look into a shared drive. https://shallowsky.com/blog/linux/qemu- … older.html
- Isn't -net deprecated? You may want to try the -nic or -netdev options instead. https://wiki.qemu.org/Documentation/Networking
For example, I have a QEMU system that uses a NAT and Host-Only network with the following configuration:
~$ qemu-system-x86_64 \
...
# NAT/Shared network
-device e1000,mac=D6:CF:07:FD:63:BD,netdev=net0 \
-netdev user,id=net0 \
# Host-Only network.
-device e1000,mac=B6:4D:E5:F7:B9:94,netdev=net1 \
-netdev tap,id=net1,ifname=tap0 \
...For a host-only network, you may need to define the interface yourself. There are a few guides on how to do so. This one worked for me, but you may need to install dnsmasq and tweak the interface names or IP ranges: https://alberand.com/host-only-networki … visor.html. I updated the above code block to reflect the guide.
#13 Re: Installation » all the new kernel disturb some old PC's! » 2024-01-01 18:08:53
Sounds like this is no longer a discussion about installing Devuan.
#14 Re: Installation » all the new kernel disturb some old PC's! » 2023-12-28 16:14:55
siva wrote:Just a little throw-in here...I don't mean to take it off-topic.
I still don't understand what specific issue OP is facing. I referenced that old ad to lighten the mood and it backfired apparently.
I wondered if part of OP's issue is related to the 32-bit kernel. Anyone using i386/32-bit should expect to see issues over a long stretch since a lot of projects are moving away from supporting it.
#15 Re: Installation » all the new kernel disturb some old PC's! » 2023-12-27 17:34:00
What can be the only one conclusion?
#16 Re: Off-topic » Refracta-SnapShot - Question » 2023-12-24 19:11:25
I don't know why that 'zcat' is there when initrd is uncompressed.
Which kernel/OS are you running?
#17 Re: Off-topic » Should a display server contain a drawing API ? » 2023-12-22 20:51:39
But why should it have a drawing api ?
I misunderstood your intention. I think what you're asking about is closer to Cairo or DRM. If so, have a look at how X11/Wayland approach them to get a better idea of whether it makes sense for your (hypothetical?) use case.
Have a look at these articles:
- https://en.wikipedia.org/wiki/Direct_Rendering_Manager
- https://www.uninformativ.de/blog/postin … NG-en.html
- https://unix.stackexchange.com/a/596895
- https://news.ycombinator.com/item?id=20379336
#18 Re: Off-topic » Should a display server contain a drawing API ? » 2023-12-22 16:49:02
Assuming also the simplest b/w OGD supporting one resolution how difficult would be to implement it ?
It may take some elbow grease.
Should NHDS support also a drawing API ?
yes.
should it ... leave a user app draw whatever it likes directly to the portion of the GM thats was handed to it
no.
Also what is the relation of NHDS to the kernel ?
Minimally, it should only provide the bare-minimum interaction with the kernel (only if/when absolutely needed) on behalf of the clients. The end result should enforce the least-privilege principle for any client that interacts with the display server. See the architecture diagrams here: https://wayland.freedesktop.org/architecture.html
Sure NHDS must access OGDDs . But does it need something more? Access to memory ? To filesystem ? But if kernel controls access to memory how GM is different ? Isnt it memory ? Isnt that strange ? Kernel mediates and supervise access to memory to hundrers of processes and GM supervision could be NOT part of the kernel ?
I would look into the X11 and Wayland source code in order to answer these questions.
You may also want to research how the Android API exposes some bare-metal GPU functionalities in C++, keeping an eye on how this approach enforces a least-privilege principle with respect to the Android API and kernel relationships. https://developer.android.com/games/agd … e-graphics
#19 Re: Installation » [SOLVED] chimaera in vm on m1 mac » 2023-12-19 14:28:45
Still long and gross imo. While the line-breaks improve readability, my intention was to give a peek at the scale of the command without subjecting everyone on the thread to actually read it unless they really want to. 
#20 Re: Off-topic » "A future for the i386 architecture" and other good(???) news » 2023-12-19 14:23:01
Maybe devuan will try to support 32-bit long term.
#21 Re: Other Issues » [SOLVED] A folder with no name » 2023-12-19 07:38:47
Malware? Might be time for a fresh install/restore.
You could also use auditd to do some hunting. The output won't show you the Parent PID directly, but you could try to correlate it yourself.
~# apt install auditd
...
~# /sbin/auditctl -w / -p rw -k var-run-pids -S allIn your case, you could check for PATH events which follow folder-creation syscall events whose name contains some sequence of "20," the hex encoding for a space.
# Create a folder whose name is a space.
~$ mkdir ' '
# Start the hunt.
~$ grep -B 4 -A 5 'exe="/bin/mkdir"' /var/log/audit/audit.log
...
type=SYSCALL msg=audit(1702969127.472:12053): arch=c00000b7 syscall=34 success=yes exit=0 a0=ffffffffffffff9c a1=ffffc4ba4745 a2=1ff a3=ffffc4ba35c0 items=2 ppid=7307 pid=8072 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=5 comm="mkdir" exe="/bin/mkdir" subj=unconfined key="var-run-pids"ARCH=aarch64 SYSCALL=mkdirat AUID="devuan" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
type=CWD msg=audit(1702969127.472:12053): cwd="/home/devuan/velociraptor"
type=PATH msg=audit(1702969127.472:12053): item=0 name="/home/devuan/velociraptor" inode=392843 dev=fe:02 mode=040755 ouid=1000 ogid=1000 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID="devuan" OGID="devuan"
type=PATH msg=audit(1702969127.472:12053): item=1 name=20 inode=392733 dev=fe:02 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID="root" OGID="root"
type=PROCTITLE msg=audit(1702969127.472:12053): proctitle=6D6B6469720020Here, the pathname is name=20, which is a single space. The parent process ID of /bin/mkdir is 7303, which is bash on my system. You can use tree-generating tools like ps or htop to visually trace the PPID's parents or children.
You could also leverage something like Graylog, ELK/HELK, or Splunk free to make this easier. Still, this kind of thing would take some legwork, might not give you the results you want.
You could also check automated routines like cron/tab and maybe run an antivirus/antimalware.
#22 Re: Installation » [SOLVED] chimaera in vm on m1 mac » 2023-12-19 01:25:38
@kraiken: Thanks for the write-up! I've never worked with any of the mini.iso installers. The latest arm64 build worked like a charm in my lab environment.
Another interesting feature of UTM is that you can export the entire QEMU command. The result is a rather long and ugly one-liner, but it's still useful to have a one-to-one copy if you want to run the image on another system. In any case, it's a nice step towards "using macOS as a glorified hypervisor."
Example:
qemu-system-aarch64 -L /Applications/UTM.app/Contents/Resources/qemu -S -spice "unix=on,addr=/Users/lab/Library/Group Containers/WDNLXAD4W8.com.utmapp.UTM/D56EF667-607C-4108-B511-3E87DC8F6776.spice,disable-ticketing=on,image-compression=off,playback-compression=off,streaming-video=off,gl=off" -chardev spiceport,id=org.qemu.monitor.qmp,name=org.qemu.monitor.qmp.0 -mon chardev=org.qemu.monitor.qmp,mode=control -nodefaults -vga none -device virtio-net-pci,mac=B2:2E:F8:E5:00:95,netdev=net0 -netdev vmnet-shared,id=net0 -device virtio-gpu-pci -cpu host -smp cpus=6,sockets=1,cores=6,threads=1 -machine virt -accel hvf -drive if=pflash,format=raw,unit=0,file=/Applications/UTM.app/Contents/Resources/qemu/edk2-aarch64-code.fd,readonly=on -drive "if=pflash,unit=1,file=/Users/lab/Library/Containers/com.utmapp.UTM/Data/Documents/Devuan Daedalus ARM64.utm/Data/efi_vars.fd" -m 2048 -audiodev coreaudio,id=audio0 -device intel-hda -device hda-duplex,audiodev=audio0 -device nec-usb-xhci,id=usb-bus -device usb-tablet,bus=usb-bus.0 -device usb-mouse,bus=usb-bus.0 -device usb-kbd,bus=usb-bus.0 -device qemu-xhci,id=usb-controller-0 -chardev spicevmc,name=usbredir,id=usbredirchardev0 -device usb-redir,chardev=usbredirchardev0,id=usbredirdev0,bus=usb-controller-0.0 -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=usb-controller-0.0 -chardev spicevmc,name=usbredir,id=usbredirchardev2 -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=usb-controller-0.0 -device usb-storage,drive=drive1EDBA7C9-D708-4C56-889C-724AFD3A82E2,removable=true,bootindex=0,bus=usb-bus.0 -drive if=none,media=cdrom,id=drive1EDBA7C9-D708-4C56-889C-724AFD3A82E2,readonly=on -device virtio-blk-pci,drive=drive3F574F35-CB41-4D38-BCCD-B32FA8EBA224,bootindex=1 -drive "if=none,media=disk,id=drive3F574F35-CB41-4D38-BCCD-B32FA8EBA224,file=/Users/lab/Library/Containers/com.utmapp.UTM/Data/Documents/Devuan Daedalus ARM64.utm/Data/3F574F35-CB41-4D38-BCCD-B32FA8EBA224.qcow2,discard=unmap,detect-zeroes=unmap" -device virtio-serial -device virtserialport,chardev=org.qemu.guest_agent,name=org.qemu.guest_agent.0 -chardev spiceport,id=org.qemu.guest_agent,name=org.qemu.guest_agent.0 -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 -chardev spicevmc,id=vdagent,debug=0,name=vdagent -name "Devuan Daedalus ARM64" -uuid D56EF667-607C-4108-B511-3E87DC8F6776 -device virtio-rng-pci#23 Off-topic » Terrapin SSH vulnerability » 2023-12-18 18:52:00
- siva
- Replies: 1
CVE Page: https://nvd.nist.gov/vuln/detail/CVE-2023-48795
Article: https://terrapin-attack.com/
Terrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it.
The attack can be performed in practice, allowing an attacker to downgrade the connection's security by truncating the extension negotiation message (RFC8308) from the transcript. The truncation can lead to using less secure client authentication algorithms and deactivating specific countermeasures against keystroke timing attacks in OpenSSH 9.5.
We also showed that Terrapin can be used to enable the exploitation of implementation flaws. For example, we found several weaknesses in the AsyncSSH servers' state machine, allowing an attacker to sign a victim's client into another account without the victim noticing. Hence, it will enable strong phishing attacks and may grant the attacker Man-in-the-Middle (MitM) capabilities within the encrypted session.
To perform the Terrapin attack in practice, we require MitM capabilities at the network layer (the attacker must be able to intercept and modify the connection's traffic). Additionally, the connection must be secured by either ChaCha20-Poly1305 or CBC with Encrypt-then-MAC. However, our scan indicates an extensive adoption of these encryption modes; therefore, Terrapin applies to most real-world SSH sessions.
Quick and dirty run of the scanner:
$ go version
go version go1.21.4 linux/arm64
$ git clone https://github.com/RUB-NDS/Terrapin-Scanner/
Cloning into 'Terrapin-Scanner'...
remote: Enumerating objects: 41, done.
remote: Counting objects: 100% (41/41), done.
remote: Compressing objects: 100% (26/26), done.
remote: Total 41 (delta 17), reused 32 (delta 12), pack-reused 0
Receiving objects: 100% (41/41), 13.50 KiB | 1.35 MiB/s, done.
Resolving deltas: 100% (17/17), done.
$ cd Terrapin-Scanner
$ mkdir bin
$ env GOBIN="$(pwd)/bin" go install github.com/RUB-NDS/Terrapin-Scanner@latest
go: downloading github.com/RUB-NDS/Terrapin-Scanner v1.0.2
$ cd bin
$ ls
Terrapin-Scanner
$ ssh devuan@10.37.130.8 "ssh -V && uname -a && lsb_release -a"
devuan@10.37.130.8's password:
OpenSSH_9.2p1 Debian-2+deb12u1, OpenSSL 3.0.11 19 Sep 2023
Linux devuan 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-1 (2023-07-14) x86_64 GNU/Linux
Distributor ID: Devuan
Description: Devuan GNU/Linux 5 (daedalus)
Release: 5
Codename: daedalus
$ ./Terrapin-Scanner -connect 10.37.130.8:22
================================================================================
==================================== Report ====================================
================================================================================
Remote Banner: SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u1
ChaCha20-Poly1305 support: true
CBC-EtM support: false
Strict key exchange support: false
==> The scanned peer is VULNERABLE to Terrapin.
Note: This tool is provided as is, with no warranty whatsoever. It determines
the vulnerability of a peer by checking the supported algorithms and
support for strict key exchange. It may falsely claim a peer to be
vulnerable if the vendor supports countermeasures other than strict key
exchange.
For more details visit our website available at https://terrapin-attack.com
$#24 Re: Other Issues » Technical discussion of the Wayland protocol or implementation » 2023-12-18 17:57:32
@mods: Apologies, this belongs in Off-Topic.
#25 Other Issues » Technical discussion of the Wayland protocol or implementation » 2023-12-18 17:45:34
- siva
- Replies: 2
I wanted to probe the group for any technical insights, critiques, or concerns regarding Wayland's protocol (high-level workflows) or implementation (specifications or APIs).
Something I'm curious about is whether Xwayland is an acceptable workaround for systems that enforce Wayland, with the understanding that a better one might be for projects to support X and Wayland independently.
Something I'm also curious about is how Wayland's security, whether in the design or specification, compares with X/X11. The trust boundaries seem comparable at a high level, so any insight here is appreciated.
References
Official Wayland docs: https://wayland-book.com/protocol-desig … tocol.html
Wayland Freedesktop.org docs: https://wayland.freedesktop.org/docs/html/
X11 protocol: https://www.x.org/releases/current/doc/ … tocol.html
Wayland source code: https://gitlab.freedesktop.org/wayland/wayland
"State of Wayland" semi-opinion piece: https://gist.github.com/probonopd/9feb7 … 9f2d1f2277
Board footer
